Maxima newb here. I need to check that an expression is of the form constant + infinite sum of trigonometric terms Is there a good way to do this - with or without a block?
There isn't a built-in way to do exactly that, but I think you can use the pattern-matching functions (i.e., for matching expressions, not strings) for this purpose. Something like:
matchdeclare (xx, trigtermp(x));
matchdeclare (yy, freeof(x));
defrule (myrule1, xx + yy, HEY(xx, yy));
where trigtermp is itself a pattern-matching function which matches (multiplicative factor)*(trig function). My advice is read a little about matchdeclare, defrule, and defmatch in the reference manual, and maybe follow up with the Maxima mailing list (maxima-discuss#lists.sourceforge.net) as this problem probably needs some additional discussion.
Related
I'm writing a tool which reads go code and parses some duration expressions like: dur := 5 * time.Minute. I already have the parsing step done and got a *ast.BinaryExpr. How can I evaluate this expression and get its value?
Is there something in the toolchain/packages or do I need to go by hand?
I think parser package is the one your looking for.
go also has a package named eval (https://godoc.org/github.com/apaxa-go/eval) that evaluates expressions.
And there are two libraries that might help you down the line.
https://github.com/PaesslerAG/gval
https://github.com/Knetic/govaluate
Gval (Go eVALuate) provides support for evaluating arbitrary expressions, in particular Go-like expressions.
Good luck!
I would write a function which can parse the multiplication of 2 algebraic expressions in GF(2), i.e any variable in the expression only take on 2 possible values 0 or 1, so a^2 = a,(0^2 = 0, 1^2 = 1)
As an example, if we expand (a+b)*(a+c) in GF(2), we should get
(a + b)*(a + c) = a^2 + a*b + a*c + b*c = a + a*b + a*c + b*c.
However, I am not sure how to start about the parsing of 2 algebraic expressions using strings. Any suggestion/ help is appreciated. Thanks!
I would recommend taking a look at OMeta, by Alex Warth, and/or PetitParser, by Lucas Rengli. Both are excellent frameworks for writing parsers. The first one is for JS, the second for Smalltalk.
Here are some few initial lines of code showing how to write your parser in PetitParser. Every fragment is a method of your own subclass of PPCompositeParser.
constant
ˆ$0 asParser / $1 asParser
variable
^#letter asParser
timesOp
^#blank asParser star , $* asParser, #blank asParser star
sumOp
^#blank asParser star, $* asParser, #blank asParser star
element
^self constant / self variable
term
^self element , (self timesOp , self element) star
etc.
I'm not saying this is trivial. I'm only saying that this is where I would start. Note also that once you have your grammar in place you might want to subclass it so you can generate more appropriate productions, etc.
Writing parsers for big complicated languages can be hard. But writing parsers for algebraic expressions (GF(2) or otherwise) is pretty easy.
See my SO answer on how to write such parsers easily: Is there an alternative for flex/bison that is usable on 8-bit embedded systems?
The GF(2) bit is about semantic interpretation of what such a formula means. It doesn't matter at all for parsing, which is purely about syntax.
Where meaning comes into play is when you want to interpret the formula.
At some point, you may want to evaluate the expression using values for the variables. To do that, you have to capture the formula as a data structure (usually called an (abstract) syntax tree), and then walk that tree to compute the desired result. That link also discusses how to do that.
If you want to manipulate the formula symbolically, you're in an entirely different ball game. Parsing is still easy, but formula manipulation is not, and you'll want to use tools that are designed to do such symbolic manipulation; they generally define thier own parsing machinery (and make it easy to use) to ensure that the captured parse can be manipulated. And of course, you'll have to define what the rules of you symbolic manipulation are.
You can see an example of how to write something pretty close to your needs at Symbolic Algebra with a program transformation system. (This a tool that my company builds).
I need to convert a math formula written in the Latex style to the function of a C/C++ code.
For example:
y = sin(x)^2 would become something like
double y = sin(x) * sin(x);
or
double y = pow(sin(x), 2);
where x is a variable defined somewhere before.
I mean that it should convert the latex formula to the C/C++ syntax. So that if there is a function y = G(x, y)^F(x) it doesn't matter what is G(x,y) and F(x),
it is a problem of the programmer to define it. It will just generate
double y = pow(G(x, y), F(x));
When the formula is too complicated it will take some time to make include it in the C/C++ formula. Is there any way to do this conversion?
Emacs' built-in calculator calc-mode can do this (and much more). Your examples can be converted like this:
Put the formula in some emacs buffer
$ y = sin(x)^2 $
With the cursor in the formula, activate calc-embedded mode
M-x calc-embedded
Switch the display language to C:
M-x calc-c-language
There you are:
$ y == pow(sin(x), 2) $
Note that it interprets the '=' sign in latex as an equality, which results in '==' for C. The latex equivalent to Cs assignment operator '=' would be '\gets'.
More on this topic on Turong's blog
I know the question is too old, but I'll just add a reply anyway as a think it might help someone else later. The question popped up a lot for me in my searches.
I'm working on a tool that does something similar, in a public git repo
You'll have to put some artificial limitations on your latex input, that's out of question.
Currently the tool I wrote only supports mul, div, add, sub, sqrt, pow, frac and sum as those are the only set of operations I need to handle, and the imposed limitations can be a bit loose by providing a preprocessor (see preproc.l for an [maybe not-so-good] example) that would clean away the raw latex input.
A mathematical equation, such as the ones in LaTeX, and a C expression are not interchangeable. The former states a relation between two terms, the latter defines an entity that can be evaluated, unambiguously yielding one value. a = b in C means 'take the value in variable b and store it in variable a', wheres in Math, it means 'in the current context, a and b are equal'. The first describes a computation process, the second describes a static fact. Consequently, the Math equation can be reversed: a = b is equivalent to b = a, but doing the same to the C equation yields something quite different.
To make matters worse, LaTeX formulae only contain the information needed to render the equations; often, this is not enough to capture their meaning.
Of course some LaTeX formulae, like your example, can be converted into C computations, but many others cannot, so any automated way of doing so would only make limited sense.
I'm not sure there is a simple answer, because mathematical formulaes (in LaTeX documents) are actually ambiguous, so to automate their translation to some code requires automating their understanding.
And the MathML standard has, IIRC, two forms representing formulaes (one for displaying, another for computing) and there is some reason for that.
I'm trying to parse a syntax using the Shunting Yard (SY) algorithm. The syntax includes the following commands (they're are many many others though!)
a + b // a and b are numbers
setxy c d //c,d can be numbers
setxy c+d b+a //all numbers
Essentially, setxy is a function but it doesn't expect any function argument separators. This makes it very difficult (impossible?) to do via SY due to the lack of parens and function argument separators.
Any idea if SY can be used to parse a parentheses-less/function argument separator-less function or should I move on to a different parsing algorithm? If so, which one would you recommend?
Thanks!
djs22
Having defined correct grammar you can make http://www.antlr.org/ generate parser for you. Whether it is appropriate solution depends on your homework "requirements".
At least you can generate it and look inside for some hints.
I don't fully understand what you are trying to do, but perhaps you could use some regex? what are you trying to do write a simple command line program?
I've been mulling over creating a language that would be extremely well suited to creation of DSLs, by allowing definitions of functions that are infix, postfix, prefix, or even consist of multiple words. For example, you could define an infix multiplication operator as follows (where multiply(X,Y) is already defined):
a * b => multiply(a,b)
Or a postfix "squared" operator:
a squared => a * a
Or a C or Java-style ternary operator, which involves two keywords interspersed with variables:
a ? b : c => if a==true then b else c
Clearly there is plenty of scope for ambiguities in such a language, but if it is statically typed (with type inference), then most ambiguities could be eliminated, and those that remain could be considered a syntax error (to be corrected by adding brackets where appropriate).
Is there some reason I'm not seeing that would make this extremely difficult, impossible, or just a plain bad idea?
Edit: A number of people have pointed me to languages that may do this or something like this, but I'm actually interested in pointers to how I could implement my own parser for it, or problems I might encounter if doing so.
This is not too hard to do. You'll want to assign each operator a fixity (infix, prefix, or postfix) and a precedence. Make the precedence a real number; you'll thank me later. Operators of higher precedence bind more tightly than operators of lower precedence; at equal levels of precedence, you can require disambiguation with parentheses, but you'll probably prefer to permit some operators to be associative so you can write
x + y + z
without parentheses. Once you have a fixity, a precedence, and an associativity for each operator, you'll want to write an operator-precedence parser. This kind of parser is fairly simply to write; it scans tokens from left to right and uses one auxiliary stack. There is an explanation in the dragon book but I have never found it very clear, in part because the dragon book describes a very general case of operator-precedence parsing. But I don't think you'll find it difficult.
Another case you'll want to be careful of is when you have
prefix (e) postfix
where prefix and postfix have the same precedence. This case also requires parentheses for disambiguation.
My paper Unparsing Expressions with Prefix and Postfix Operators has an example parser in the back, and you can download the code, but it's written in ML, so its workings may not be obvious to the amateur. But the whole business of fixity and so on is explained in great detail.
What are you going to do about order of operations?
a * b squared
You might want to check out Scala which has a kind of unique approach to operators and methods.
Haskell has just what you're looking for.