Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1152 > unrolled thread

parser tokens

Back to article view | Back to comp.programming

Contents

  parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-29 22:46 -0500
    Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 10:50 +0100
      Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:54 +0000
        Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 16:26 +0100
          Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 16:09 +0000
            Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 18:22 +0100
              Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 19:33 +0000
                Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 23:08 +0100
    Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-30 12:09 +0000
      Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:43 +0000
        Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-31 08:48 +0000
    Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:23 +0000
    Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-30 23:41 +0000
      Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-31 18:26 -0500
        Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 01:51 +0000
          Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2012-01-01 12:17 -0500
            Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 22:17 +0000
              Re: parser tokens "BartC" <bc@freeuk.com> - 2012-01-01 22:54 +0000

#1152 — parser tokens

    I know in writing a parser there are tokens involved. Would strtok be 
used? I am wanting to do this in C also.

Bill

[toc] | [next] | [standalone]

#1153

On Thu, 29 Dec 2011 22:46:59 -0500, Bill Cunningham wrote:

>     I know in writing a parser there are tokens involved. Would strtok be 
> used?

30 years ago, maybe. I wonder if anybody would do it for a hand-written
parser now.

Modern techniques allow parsing in just one pass directly connected to the
semantics analysis. So you just skip tokenizing and go directly to the
semantic callbacks. As a by-product you get an excellent error reporting
and handling abilities.

> I am wanting to do this in C also.

I would suggest a language with OO support. It is much more elegant and
easier to implement a table-driven parser in an OOPL. Note also that it
would allow you to properly abstract the source. You certainly wanted the
parser working on streams, files, text buffers (e.g. GUI), with different
encodings.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1158

Dmitry A. Kazakov wrote:

>> I am wanting to do this in C also.
> 
> I would suggest a language with OO support. It is much more elegant and
> easier to implement a table-driven parser in an OOPL. 

I don't see why.  A LL parser only requires a stack and a table, and an 
object-oriented programming language isn't required to implement any of 
those data structures.


> Note also that it
> would allow you to properly abstract the source. You certainly wanted the
> parser working on streams, files, text buffers (e.g. GUI), with different
> encodings.

Again, I don't see why.  If you buffer the data stream then you can scan the 
buffered data without knowing where the data came from.  You just abstract 
the routine which fills the buffer and go on with your business.  You don't 
need an OO language to do something which can easily be done with basic C 
techniques, such as function pointers.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1159

On Fri, 30 Dec 2011 14:54:28 +0000, Rui Maciel wrote:

> Dmitry A. Kazakov wrote:
> 
>>> I am wanting to do this in C also.
>> 
>> I would suggest a language with OO support. It is much more elegant and
>> easier to implement a table-driven parser in an OOPL. 
> 
> I don't see why.  A LL parser only requires a stack and a table, and an 
> object-oriented programming language isn't required to implement any of 
> those data structures.

That depends on what you mean. If you do Turing-completeness, then yes, you
could implement it in C, Forth, Assembler, machine code, even in Convey's
Life gliders.

If stack and table are handled as abstract data types (ADT), rather than
data structures, then OO gets handy. In fact there is no need to expose
stack (or stacks) at all. OO allows you to encapsulate the parser's state
as an opaque ADT. What is inside is no concern to the end user. And again,
good design is always rewarded. You get the parser reentrant and recursive
for free.

>> Note also that it
>> would allow you to properly abstract the source. You certainly wanted the
>> parser working on streams, files, text buffers (e.g. GUI), with different
>> encodings.
> 
> Again, I don't see why.  If you buffer the data stream then you can scan the 
> buffered data without knowing where the data came from.  You just abstract 
> the routine which fills the buffer and go on with your business.  You don't 
> need an OO language to do something which can easily be done with basic C 
> techniques, such as function pointers.

I prefer proper abstractions, which do not leak. I am too old to enjoy
walking minefields of low-level C programming.

OOPL does these function pointers for me automatically. Why should I waste
my time on re-implementing the OOPL's run-time library, testing and
debugging it, rather than focusing on the main objective?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1160

Dmitry A. Kazakov wrote:

> On Fri, 30 Dec 2011 14:54:28 +0000, Rui Maciel wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>>> I am wanting to do this in C also.
>>> 
>>> I would suggest a language with OO support. It is much more elegant and
>>> easier to implement a table-driven parser in an OOPL.
>> 
>> I don't see why.  A LL parser only requires a stack and a table, and an
>> object-oriented programming language isn't required to implement any of
>> those data structures.
> 
> That depends on what you mean. If you do Turing-completeness, then yes,
> you could implement it in C, Forth, Assembler, machine code, even in
> Convey's Life gliders.
> 
> If stack and table are handled as abstract data types (ADT), rather than
> data structures, then OO gets handy. 

Why do you even need to abstract the stack and the table of a meek parser?  
One is used to store symbols, the other is used to map a pair of symbols to 
a state.  What do you gain by abstracting any of these components? And why 
do you believe that you need an OO language to abstract data?


> In fact there is no need to expose
> stack (or stacks) at all. OO allows you to encapsulate the parser's state
> as an opaque ADT. What is inside is no concern to the end user. And again,
> good design is always rewarded. 


> You get the parser reentrant and recursive
> for free.

It's widely known that recursive parsers are a bad idea.  All they do is 
replace the parser's stack with the call stack, and that in turn opens the 
door to nasty problems such as stack buffer overflows and associated 
security problems.


>> Again, I don't see why.  If you buffer the data stream then you can scan
>> the
>> buffered data without knowing where the data came from.  You just
>> abstract
>> the routine which fills the buffer and go on with your business.  You
>> don't need an OO language to do something which can easily be done with
>> basic C techniques, such as function pointers.
> 
> I prefer proper abstractions, which do not leak. I am too old to enjoy
> walking minefields of low-level C programming.

Please do tell how you go from using a function pointer to causing leaks. 
Then, please explain how you interpret basic stuff such as function pointers 
as "a walking minefield of low-level C programming".


> OOPL does these function pointers for me automatically. Why should I waste
> my time on re-implementing the OOPL's run-time library, testing and
> debugging it, rather than focusing on the main objective?

Your statement is quite odd.  First you suggest that a user abandons C in 
favour of an OO language, and then you complain that you shouldn't be forced 
to waste your time re-implementing things, along with testing and debugging 
them.  This is a considerable contradiction.

Frankly, it sounds an awful lot like the only tool you have is the 
proverbial hammer, consisting of a rather limited view on OO programming, 
and therefore you see every single problem which you face as being the 
proverbial nail.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1161

On Fri, 30 Dec 2011 16:09:32 +0000, Rui Maciel wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Fri, 30 Dec 2011 14:54:28 +0000, Rui Maciel wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>>> I am wanting to do this in C also.
>>>> 
>>>> I would suggest a language with OO support. It is much more elegant and
>>>> easier to implement a table-driven parser in an OOPL.
>>> 
>>> I don't see why.  A LL parser only requires a stack and a table, and an
>>> object-oriented programming language isn't required to implement any of
>>> those data structures.
>> 
>> That depends on what you mean. If you do Turing-completeness, then yes,
>> you could implement it in C, Forth, Assembler, machine code, even in
>> Convey's Life gliders.
>> 
>> If stack and table are handled as abstract data types (ADT), rather than
>> data structures, then OO gets handy. 
> 
> Why do you even need to abstract the stack and the table of a meek parser? 

Because there could be thousands different ways to implement either. There
are ready-to-use components providing them. The choice should have no
influence on the parser itself.

> One is used to store symbols, the other is used to map a pair of symbols to 
> a state.  What do you gain by abstracting any of these components? And why 
> do you believe that you need an OO language to abstract data?

Abstract data type /= abstract data.

>> In fact there is no need to expose
>> stack (or stacks) at all. OO allows you to encapsulate the parser's state
>> as an opaque ADT. What is inside is no concern to the end user. And again,
>> good design is always rewarded. 
> 
>> You get the parser reentrant and recursive for free.
> 
> It's widely known that recursive parsers are a bad idea.  All they do is 
> replace the parser's stack with the call stack, and that in turn opens the 
> door to nasty problems such as stack buffer overflows and associated 
> security problems.

See what happens when things aren't properly abstracted?

If the parser state is an object, what should prevent you from having a
stack of such objects allocated anywhere you wanted?

You jump to a certain implementation without even considering any possible
alternatives.

>>> Again, I don't see why.  If you buffer the data stream then you can scan the
>>> buffered data without knowing where the data came from.  You just abstract
>>> the routine which fills the buffer and go on with your business.  You
>>> don't need an OO language to do something which can easily be done with
>>> basic C techniques, such as function pointers.
>> 
>> I prefer proper abstractions, which do not leak. I am too old to enjoy
>> walking minefields of low-level C programming.
> 
> Please do tell how you go from using a function pointer to causing leaks.

Abstraction leaks when implementation details get exposed and can be
unintentionally or improperly used.

>> OOPL does these function pointers for me automatically. Why should I waste
>> my time on re-implementing the OOPL's run-time library, testing and
>> debugging it, rather than focusing on the main objective?
> 
> Your statement is quite odd.  First you suggest that a user abandons C in 
> favour of an OO language, and then you complain that you shouldn't be forced 
> to waste your time re-implementing things, along with testing and debugging 
> them.  This is a considerable contradiction.

I don't see any contradiction. The point was that in a low-level language
like C, I would be forced to implement some parts of the RTL already
present in the higher level languages, extensively tested and debugged. Why
should I reinvent the wheel, the dispatching table in this case?

25 years ago I used to write a lot of compiler stuff in K&R and ANSI C. I
don't want back.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1162

Dmitry A. Kazakov wrote:

>> Why do you even need to abstract the stack and the table of a meek
>> parser?
> 
> Because there could be thousands different ways to implement either. There
> are ready-to-use components providing them. The choice should have no
> influence on the parser itself.

Why do you believe that you need to simultaneously support thousands 
different ways of implementing a single parser for the very same language?  
Even if you need to parse a completely different language then basicaly you 
only need to define the tokens, the lexer and the parser table, which are 
specific to each language.  This is easily done in any programming paradigm, 
and it is done so in a very simple and straight forward way in C.  So why 
should anyone rewrite everything following the OO paradigm just to end up 
doing something they already do quite well?


>> One is used to store symbols, the other is used to map a pair of symbols
>> to
>> a state.  What do you gain by abstracting any of these components? And
>> why do you believe that you need an OO language to abstract data?
> 
> Abstract data type /= abstract data.

I referred to your previous ADT claim.


>> It's widely known that recursive parsers are a bad idea.  All they do is
>> replace the parser's stack with the call stack, and that in turn opens
>> the door to nasty problems such as stack buffer overflows and associated
>> security problems.
> 
> See what happens when things aren't properly abstracted?

What does the use of recursive functions has to do with "things not being 
properly abstracted"?


> If the parser state is an object, what should prevent you from having a
> stack of such objects allocated anywhere you wanted?
> 
> You jump to a certain implementation without even considering any possible
> alternatives.

This is a strange accusation, as your attempt to justify replacing C with a 
language which explicitly supports OO programming is based on a failure to 
consider any possible alternatives to the OO paradigm.


>> Please do tell how you go from using a function pointer to causing leaks.
> 
> Abstraction leaks when implementation details get exposed and can be
> unintentionally or improperly used.

I don't understand what you are trying to say.  Are you trying to say that 
using function pointers causes leaks because a programmer may write buggy 
code?


>> Your statement is quite odd.  First you suggest that a user abandons C in
>> favour of an OO language, and then you complain that you shouldn't be
>> forced to waste your time re-implementing things, along with testing and
>> debugging
>> them.  This is a considerable contradiction.
> 
> I don't see any contradiction. The point was that in a low-level language
> like C, I would be forced to implement some parts of the RTL already
> present in the higher level languages, extensively tested and debugged.
> Why should I reinvent the wheel, the dispatching table in this case?

Why are you talking about RTL and dispatching tables?  Again, it appears you 
are striking that proverbial OO hammer pretty hard for a problem which 
doesn't even resemble a nail.  If it is terribly simple to solve problem 
with basic structured programming techniques then why do you believe that a 
programmer should abandon a specific programming language in favour of one 
which supports your hammer, the OO paradigm?


> 25 years ago I used to write a lot of compiler stuff in K&R and ANSI C. I
> don't want back.

No one is forcing you to abandon OO.  Yet, that doesn't explain why anyone 
should rewrite a project in an OO language just to be able to develop a 
simple parser.  Up until now, the only objective justification you've 
presented was that with OO you could parse streams, files, text buffers, 
stuff which is easily done with non-OO programming.  So, exactly what's the 
point of abandoning C in favour of a OO language just to be able to perform 
such a simple task?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1164

On Fri, 30 Dec 2011 19:33:57 +0000, Rui Maciel wrote:

> Dmitry A. Kazakov wrote:
> 
>>> Why do you even need to abstract the stack and the table of a meek
>>> parser?
>> 
>> Because there could be thousands different ways to implement either. There
>> are ready-to-use components providing them. The choice should have no
>> influence on the parser itself.
> 
> Why do you believe that you need to simultaneously support thousands 
> different ways of implementing a single parser for the very same language?

Why simultaneously?
Why parser?

[The point was about decoupling the parser from stack implementation.]

> Even if you need to parse a completely different language then basicaly you 
> only need to define the tokens, the lexer and the parser table, which are 
> specific to each language.  This is easily done in any programming paradigm, 
> and it is done so in a very simple and straight forward way in C.  So why 
> should anyone rewrite everything following the OO paradigm just to end up 
> doing something they already do quite well?

You should ask this question yourself. Why to re-write the parser if the
stack implementation changes? E.g. to have one implementation for a 64-bit
machine with flat memory and another for a 16-bit machine with an ability
to swap stack pages in physical memory?

>>> One is used to store symbols, the other is used to map a pair of symbols to
>>> a state.  What do you gain by abstracting any of these components? And
>>> why do you believe that you need an OO language to abstract data?
>> 
>> Abstract data type /= abstract data.
> 
> I referred to your previous ADT claim.

Because OO languages have better ADT support.

>>> It's widely known that recursive parsers are a bad idea.  All they do is
>>> replace the parser's stack with the call stack, and that in turn opens
>>> the door to nasty problems such as stack buffer overflows and associated
>>> security problems.
>> 
>> See what happens when things aren't properly abstracted?
> 
> What does the use of recursive functions has to do with "things not being 
> properly abstracted"?

Recursive function calls (using physical stack) is just one possible
implementation of recursive parser. It is not the only implementation of.

>> If the parser state is an object, what should prevent you from having a
>> stack of such objects allocated anywhere you wanted?
>> 
>> You jump to a certain implementation without even considering any possible
>> alternatives.
> 
> This is a strange accusation,

Hmm, it was you who suggested this implementation [recursive calls], and
then claimed it problematic. I merely pointed out that had you used a
proper abstraction, you would be able to see other implementations as well.

> as your attempt to justify replacing C with a 
> language which explicitly supports OO programming is based on a failure to 
> consider any possible alternatives to the OO paradigm.

Do you mean here the paradigm of weakly typing and ill-defined language
semantics?

>>> Please do tell how you go from using a function pointer to causing leaks.
>> 
>> Abstraction leaks when implementation details get exposed and can be
>> unintentionally or improperly used.
> 
> I don't understand what you are trying to say. Are you trying to say that 
> using function pointers causes leaks because a programmer may write buggy 
> code?

He will.

[I have a suspicion that you are confusing memory leaks with leaking
abstractions.]

>>> Your statement is quite odd.  First you suggest that a user abandons C in
>>> favour of an OO language, and then you complain that you shouldn't be
>>> forced to waste your time re-implementing things, along with testing and
>>> debugging them.  This is a considerable contradiction.
>> 
>> I don't see any contradiction. The point was that in a low-level language
>> like C, I would be forced to implement some parts of the RTL already
>> present in the higher level languages, extensively tested and debugged.
>> Why should I reinvent the wheel, the dispatching table in this case?
> 
> Why are you talking about RTL and dispatching tables?

Function pointers you suggested is a poor man's implementation of method
overriding.

>> 25 years ago I used to write a lot of compiler stuff in K&R and ANSI C. I
>> don't want back.
> 
> No one is forcing you to abandon OO.

People starting to write a compiler today are in a much better position
than 30 years ago. I had to write compilers in MACRO-11, FORTRAN-IV and
those terrifying SysV and Sun Solaris C's. Today I am free to use far
better languages, much safer and productive, have access to reusable
components etc. Why voluntarily torture myself?

> So, exactly what's the 
> point of abandoning C in favour of a OO language just to be able to perform 
> such a simple task?

No task is simple in C. C is a complex language, very difficult to master.
C code is a maintenance nightmare.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1154

Bill Cunningham wrote:

>    I know in writing a parser there are tokens involved. Would strtok be
> used? I am wanting to do this in C also.

Probably not.  Not unless you have some other scheme in mind for categorising 
the tokens, for instance recognising that 111 and -22 are both numbers even 
though they are different tokens.

If you are working in C, and don't want to learn how to do parsing properly 
(fairly big subject, but not unintersting), then see "flex".  Also "bison" 
(yacc).

Come to that, see that pair (or some equivalent) even if you /do/ want to learn 
about proper parsing.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#1157

Chris Uppal wrote:

> If you are working in C, and don't want to learn how to do parsing
> properly (fairly big subject, but not unintersting), then see "flex". 
> Also "bison" (yacc).

According to my experience, the flex/bison combo may appear to be a bit 
simpler to work with but in the end it takes much more work to learn the 
basics and to get it up and running, at least when dealing with relatively 
simple languages.  And things don't get any simpler if you need to maintain 
the parsers (i.e., extend the language, handle parser errors, etc..)

I had a project where I had to develop and maintain a couple of parsers and 
in the end the project became easier to maintain and extend by replacing the 
whole flex/bison mess with a LL parser written by hand (minus the lexer).

YMMV, of course.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1166

Rui Maciel wrote:
> Chris Uppal wrote:
>
> > If you are working in C, and don't want to learn how to do parsing
> > properly (fairly big subject, but not unintersting), then see "flex".
> > Also "bison" (yacc).
>
> According to my experience, the flex/bison combo may appear to be a bit
> simpler to work with but in the end it takes much more work to learn the
> basics and to get it up and running, at least when dealing with relatively
> simple languages.

I don't entirely disagree.  Adding /any/ tool to the toolchain adds complexity,
and neither flex/lex nor bison/yacc are entirely trivial, especially if you
haven't used them before.  Certainly there are thresholds of complexity below
which I wouldn't bother using one or the other (there are also thresholds above
which I would require something better than either).

But I think that for a beginner, as the OP clearly is, you are more likely to
get it more or less right using a tool like flex, than if you do it by hand.
The point is that a half-baked attempt at using a tool will just fail, but a
half-baked attempt at hand-written code will produce half-baked code ;-)

OTOH, Ben has just pointed out that Bill probably wasn't talking about a parser
in the sense that I meant, anyway...

    -- chris

[toc] | [prev] | [next] | [standalone]

#1156

Bill Cunningham wrote:

>     I know in writing a parser there are tokens involved. Would strtok be
> used? I am wanting to do this in C also.

The strtok() function isn't suited for this purpose.  In fact, I suspect 
that the strtok() function doesn't have any useful purpose at all.  Let me 
explain.

To start off, a token is not a sub-string.  A token is, instead, a symbol 
which is used to represent a set which is comprised of specific sequences of 
characters.  For example, the token for a non-negative integer may be 
defined by the set (0 | [1-9][0-9]*), which means that the strings "123", 
"0", "12312312314145236347546845" represent the same token.

With this in mind, the strtok() function only returns a set of sub-strings 
from a base string, according to a given set of delimiter bytes.  This means 
that, in this context, the function actually doesn't extract tokens, which 
happens to be the whole point of performing a lexical analysis.  As a 
consequence, every sub-string which is returned by strtok() still needs to 
be analyzed in order to be able to do anything at all with the data.

If this wasn't enough, there is a long list of problems and inconveniences 
caused by strtok().  For example, the delimiter bytes required by strtok() 
are also tokens, and yet they are ignored. So, in the end the strtok() 
function only ends up needlesslly complicating things instead of helping.

A better solution is to write a routine that actually extracts tokens from 
any given string.  This type of routine, which tends to be referred to as a 
lexer or scanner, analyzes each given string character by character so that 
it identifies any character sequence as a specific token.  

Depending on the language definition, this may take some work.  Due to this, 
some tools have already been developed to help programmers with this task, 
such as flex[1] and re2c[2].  Nevertheless, if a language is simple enough 
then a lexer is also simple to develop.  For an example, check the lexer 
routine in the following example code:

http://en.wikipedia.org/wiki/LL_parser#Parser_implementation_in_C.2B.2B

So, in short, you are better off forgetting about strtok() and instead 
develop your own lexer routine.


Hope this helps,
Rui Maciel

[1] http://flex.sourceforge.net/
[2] http://re2c.org/

[toc] | [prev] | [next] | [standalone]

#1165

"Bill Cunningham" <nospam@nspam.invalid> writes:

>     I know in writing a parser there are tokens involved. Would strtok be 
> used? I am wanting to do this in C also.

Since I see your posts on comp.lang.c I think you should describe the
data you intend to parse.  The suggestions you get may vary depending on
what the input format really is.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1168

Ben Bacarisse wrote:

> Since I see your posts on comp.lang.c I think you should describe the
> data you intend to parse.  The suggestions you get may vary depending
> on what the input format really is.

    I'm still on the financial analysis kick. I had a way I thought I would 
do this and someone mentioned what I wanted was a parser. I can write 
successful functions for the indicators but I want a text file with the data 
manually typed in. Just like I sugessted on clc but I thought posting here 
would be a little more on topic. Since I'm obviously as poited out on clc 
not very familiar with fprintf's returns I thought there might be another 
way to "parse".

1 12.5 010112
1 is line one 12.5 is the price 010112 is the date.

2 12.25 010212
2 line two and so on.

I want to load some or all of this and pass it to a function on my choice 
for analysis.

Bill

[toc] | [prev] | [next] | [standalone]

#1169

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Ben Bacarisse wrote:
>
>> Since I see your posts on comp.lang.c I think you should describe the
>> data you intend to parse.  The suggestions you get may vary depending
>> on what the input format really is.
>
>     I'm still on the financial analysis kick. I had a way I thought I would 
> do this and someone mentioned what I wanted was a parser. I can write 
> successful functions for the indicators but I want a text file with the data 
> manually typed in. Just like I sugessted on clc but I thought posting here 
> would be a little more on topic. Since I'm obviously as poited out on clc 
> not very familiar with fprintf's returns I thought there might be another 
> way to "parse".
>
> 1 12.5 010112
> 1 is line one 12.5 is the price 010112 is the date.
>
> 2 12.25 010212
> 2 line two and so on.

You don't need a parser for this (not in the sense it's been used in the
thread).  Personally, I'd add a separator to the date (e.g. 01/02/12)
and I'd drop the line numbers.  Can you say why you need line numbers?
Computers are good at counting and if you read sequentially, your
program can keep track of the line numbers.

> I want to load some or all of this and pass it to a function on my choice 
> for analysis.

Often, the right starting point is to know how the data will be accessed
and "some or all" is a little vague.  Is there going to be a lot of
data?  If not, the best strategy might be to read it all and then to
select the parts you want to analyse.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1174

Ben Bacarisse wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>
>> Ben Bacarisse wrote:
>>
>>> Since I see your posts on comp.lang.c I think you should describe
>>> the data you intend to parse.  The suggestions you get may vary
>>> depending on what the input format really is.
>>
>>     I'm still on the financial analysis kick. I had a way I thought
>> I would do this and someone mentioned what I wanted was a parser. I
>> can write successful functions for the indicators but I want a text
>> file with the data manually typed in. Just like I sugessted on clc
>> but I thought posting here would be a little more on topic. Since
>> I'm obviously as poited out on clc not very familiar with fprintf's
>> returns I thought there might be another way to "parse".
>>
>> 1 12.5 010112
>> 1 is line one 12.5 is the price 010112 is the date.
>>
>> 2 12.25 010212
>> 2 line two and so on.
>
> You don't need a parser for this (not in the sense it's been used in
> the thread).  Personally, I'd add a separator to the date (e.g.
> 01/02/12) and I'd drop the line numbers.  Can you say why you need
> line numbers? Computers are good at counting and if you read
> sequentially, your program can keep track of the line numbers.
>
>> I want to load some or all of this and pass it to a function on my
>> choice for analysis.
>
> Often, the right starting point is to know how the data will be
> accessed and "some or all" is a little vague.  Is there going to be a
> lot of data?  If not, the best strategy might be to read it all and
> then to select the parts you want to analyse.

    The parts I want to analyze would be by number. The line numbers are 
more for me to read the text file and see how many things are there. Or I 
suppose a function to count and return this information would be good. This 
is the hardest part to me of this thing. The functions that are the 
indicators are simple and this thing is in early stages.

Bill

[toc] | [prev] | [next] | [standalone]

#1176

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Ben Bacarisse wrote:
<snip>
>> Often, the right starting point is to know how the data will be
>> accessed and "some or all" is a little vague.  Is there going to be a
>> lot of data?  If not, the best strategy might be to read it all and
>> then to select the parts you want to analyse.
>
>     The parts I want to analyze would be by number. The line numbers are 
> more for me to read the text file and see how many things are there. Or I 
> suppose a function to count and return this information would be good. This 
> is the hardest part to me of this thing. The functions that are the 
> indicators are simple and this thing is in early stages.

wc -l will count the lines in a file.  Every text editor I've ever
used will show you what line you are on, and many systems (e.g. Linux)
have a program to number lines (it's nl on my laptop).  I've not used a
file format with line numbers for 25 years.

You did not answer two of the questions: will there be a lot of data?
(or maybe better, how much data will there be?).  How will it be
accessed?  Maybe you thought "I want to analyze ... by number" was an
answer.  To me, that means nothing.  If you don't know in general, give
a few (different) examples of how the data will be accessed.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1177

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.0e475af48dc9ef2f6538.20120101221750GMT.87r4zj83u9.fsf@bsb.me.uk...
> "Bill Cunningham" <nospam@nspam.invalid> writes:

>>     The parts I want to analyze would be by number. The line numbers are
>> more for me to read the text file and see how many things are there. Or I

> wc -l will count the lines in a file.  Every text editor I've ever
> used will show you what line you are on, and many systems (e.g. Linux)
> have a program to number lines (it's nl on my laptop).  I've not used a
> file format with line numbers for 25 years.

If the file contains blank lines, or comments, then simple line counting 
won't work.

I sometimes use numbered entities in a file, as an extra check until the 
whole thing works.

-- 
Bartc 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web