1. Re: Matheval (was: Dos32Lib, Win32Lib)
> From: Beaumont Furniss
>
> By 'normal' are you referring to document style notation
> as is found
> in professional style math packages , some of these give
> you the ability
> to enter programming code too ; though usually C/C++ code.
By normal, I really mean mathematical notation as you would write it with
paper and pencil. Of course, some things aren't really possible, especially
in a text environment. Eventually, it may support some scripting to allow
actual algorithms, but no Eu or C code or anything like that.
> What is generated , is a syntax corrected sequence ,
> suitable for use
> within euphoria ; further evaluation might then occur using
> something
> like the evaluator that you had in the rough draft. Though
> this appears
> to be a little slow for some applications. This sequence might be
> amenable to symbolic manipulation.
>
Yeah, Matheval was never really intended for speed/computation intensive
applications. My real goal is the symbolic manipulation.
> The rough draft was what I found myself evaluating , I'd
> like to see
> something that is without the hiccups , perhaps in shrouded
> form ; if
> you wish to protect your code.
>
Unfortunately, the project has been shelved for a while...ran into a brick
wall, where the only solution I see is a dramatic slash and burn and a new
approach to my pattern recognition/substitution algorithms. Maybe I'll
bring it back out and polish up the parts that do seem to work.
> EU>There are several quirks about the parser and naming conventions
> EU>(eg, can't have a var begin with the same characters as
> an existing
> EU>function), but it seems to work fast enough. You would only need
> EU>to parse an expression once, and then you'd have the expression in
> EU>matheval format, able to pass it directly to the evaluation
> EU>routines.
>
> Are right brackets automatically appended now , or are these seen
> as being unnecessary clutter.
I'm not sure what you mean here.
> I'm a little unfamiliar with recursion , hence my tendency
> to bury my
> head in the sand , a bit more familarity might put me at ease with
> this approach.
>
Basically, I tried to take each operation, and make sure that it's function
'knows' how to handle any other data type (constant, matrix, etc) and return
a proper value. If an argument for the operation is some other function (or
a variable), the appropriate routine is simply called. I tend to visualize
this as 'diving into' the nested sequences, and in effect, evaluating the
most deeply nested sequences first, and passing the value 'up'. It allows
pretty easy addition of new operations.
> F(x1,x2,x3,....,xn) = type functions are readily
> available with my
> approach , is this true of yours also ?
>
This is easy to do, however, it works a little differently. Actually, there
are several ways to go about it. One would be to assign the function to
variable F:
F = Parse("x1+x2+x3+...+xn") -- we'd currently have to rename the x's
without numbers
SetVar("F", F )
SetVar("x1",x1) -- where xi is either an atom or any matheval sequence
SetVar("x2",x2)
SetVar("x3",x3)
.
.
SetVar("xn",xn)
F = Evaluate(F)
If you take a look at the regression example I posted with matheval, I take
a slightly different approach, by defining constants which hold the
functions. Granted, these aren't parsed, but written directly in matheval
sequence format.
> If you can also evaluate these and with only a few more
> lines of code
> I'm definitely interested in reviewing your approach.
>
Let's suppose you were interested in graphing x^2+x+1 over [-5,5]:
-- Begin code
include matheval.e
include G1.e -- your graphics include per parr1.txt
sequence F, f
F = Parse("x^2+X+1")
for x = -5 to 5 by .5 -- change .5 to whatever interval you'd like
SetVar("x",x)
f = Evaluate( F )
GraphPoint(x, f[2][1]) -- since f = {CONSTANT, {F(x)}, {} }
-- or whatever your graphics routine might be...
end for
-- end code
> By collapsing the token I assume you mean making a corresponding
> sequence , to the equation , that can be more quickly
> evaluated ; within
> a loop ; perhaps even an assembly language loop. To date I haven't
> bothered with this possibility as once the function has
> been defined ,
> within the editable include file I can generate an output
> sequence of
> values from an input sequence of values in the usual manner
> with just
> a few lines of euphoria code.
More or less. Everything gets mapped to a sequence. The parser makes two
passes (not counting recursive parentheses handling). The first pass
identifies functions, variables and constants, and puts them into sequences,
but most things require additional arguments. In order to properly parse
things, I have to take into account the proper order of precendence (ie, +
vs *). By collapsing, I'm really talking about shoving adjacent sequences
into each other to fill out required arguments:
"1+1" =>
{ {CONSTANT, {1},{}}, {ADD,{},{}}, {CONSTANT,{1},{} } =>
{ {ADD, {CONSTANT, {1},{}},{CONSTANT, {1},{}} } }
>
> Hence , understandably , your reluctance to be overly
> public with your
> code.
Actually, I'm fine with this stuff being public. I just don't get to work
on it much, so there's not a lot of progress. And I'd be happy if someone
else could make it better.
> With the type of
> convoluted code
> you might be involved with I'd be even more reluctant to
> post. Parsers ,
> especially small functional ones can appear to be real mind benders.
> Some of the literature surrounding these , as you're
> probably aware ,
> is pretty daunting until you break through some unknown barrier of
> comprehension. To some extent I managed this , though not
> at the basic
> level of understanding I'd prefer.
>
I think the biggest reason I made my own was that I didn't really understand
the other code/literature out there, so I came up with a solution that made
sense to me. I'm just happy that this was one occasion where it actually
worked. :)
> The sequence that contains the, syntax corrected , expression
> might be manipulated symbolically , I haven't really looked
> into this , as
> potentially , this involves more complexity than attempting
> to parse the
> sequence using the basic concepts.
Definitely more complexity. :) But a really interesting problem. It does
very simple things, so far, and if I can get the pattern match/substitution
working, it should really improve the functionality (using things like trig
id's and a table of integration). I can imagine using lot's of neat
techniques, like completing the square, or the quadratic equation.
> Anyway , I should get some text , if I don't have an
> unexpected brainwave
> first .
>
> hint:
> Associative sequences.
>
This is basically the approach that I'm taking. As an aside, I use an
associated sequence to keep track of variables.
> As this type of software might not exist , except for the features
> available through euphoria , I don't mind discussing this at all ,
> probably I should make all of the code available . A bit of scrutiny
> from more competent software developers, than I, might lead off into
> new directions.
> I suppose I could send , in plain text format , the code
> to this list
> server ; I think it's about 120k . I shall do this only if
> requested.
>
Sending to the list might not be a good idea, but I'd appreciate if you
could send it to me:
matthewlewis at hotmail.com
Matt Lewis
