1. Re: Matheval (was: Dos32Lib, Win32Lib)
> From: Beaumont Furniss
[snip]
>
> To the author of Matheval ,
>
> You may of encountered a file I posted somewhile ago
> called parr1.txt, detailing one approach to constructing a parser.
> This has a fair few advantages over other ways of evaluating equations
> or expressions. One of the disadvantages is the necessity of making at
> least two disk accesses , the parser of d.cuny circumvents this ;
however
> as you discovered in one implementation of eval.e ; there were
difficulties. Are you looking
> towards an alternative or merging of these two approaches , this is
something I was considering > for awhile and mentioned to d.cuny. He was
reticent about that approach.
> This doesn't mean that there's no other way of constructing a workable
parser with
> at least some of the attributes desired , i.e minimal use of the disk,
> ease of configuration ; rapidity of evaluation.
>
>
I did take a look at your file, and that's a very interesting approach, but
I don't think it's really suited to what I was looking to do. First, my
goal was to allow 'normal' mathematical notation, as far as possible to be
used exclusively, rather than hard coding the math into a Euphoria program.
I'd say that the version on the contributions page is a rough draft.
There are several quirks about the parser and naming conventions (eg, can't
have a var begin with the same characters as an existing function), but it
seems to work fast enough. You would only need to parse an expression once,
and then you'd have the expression in matheval format, able to pass it
directly to the evaluation routines.
I really haven't worked on the parser lately, since it works. I've been
focusing on the meat of the code, and I've been putting off fixing the other
'inconveniences' for later. I think that it is fairly easy to reconfigure.
To add a function to the parsing, you basically need to add it to the list
of functions, insert it wherever it needs to go withing the precedence
table, and write the code to 'collapse the token' (as I put it). These tend
to be no more than 5 or 6 lines of code, most of which is simply concerned
with the number of arguments required for the function.
In the development of the parser, I'd looked at David Cuny's (and a couple
of others' libs that were posted), but they didn't seem to have the right
sort of functionality that I needed, so the parsing routines are pretty much
all mine.
One reason I don't want to hard code anything is that I'm interested in
being able to manipulate the expressions symbolically--factor, integrate,
diferentiate, trig identities, etc. I can't see how you would be able to do
that using your model, since you're not really parsing the expression, but
equivalent Euphoria code.
I don't think that you've ever mentioned what your application was. I'd be
interested to see it if you've made progress.
Matt Lewis
