generating C or Java, was: Why is *print-circle* set to T by default? WAS: grinding, etc.
Subject: generating C or Java, was: Why is *print-circle* set to T by default? WAS: grinding, etc.
From: Robert Dodier
Date: Wed, 9 Feb 2011 23:26:56 -0700
My general advice is to modify the expressions of interest
via Maxima expression-hacking functions, and then output
the result with grind.
On 2/9/11, Michel Talon <talon at lpthe.jussieu.fr> wrote:
> Indeed these problems disappear. As to why i cannot start from the fortran
> command, or f90, it is because i want to produce formulas for multiprecision
> computation which have awkward syntax such as pow(x, expnt) but also
> add(x, y, z,...) instead of x+y+z, and similarly for all operations.
foo : x^2 + y^2;
foo1 : subst ("+" = add, foo);
foo2 : subst ("^" = pow, foo1);
foo2;
=> add(pow(x, 2), pow(y, 2))
> This is for using by some java program, and java doesn't allow overloading of
> operators +, *, ... so that only awkward syntax is available.
If some function needs to be a method of some class,
we can probably do something like this (for instance methods)
matchdeclare ([xx, yy], all);
defrule (r1, pow (xx, yy), xx . pow (yy));
apply1 (foo2, r1);
=> add(x . pow(2), y . pow(2))
or this (for static methods)
matchdeclare ([xx, yy], all);
defrule (r2, pow (xx, yy), FooClass . pow (xx, yy));
applyb1 (foo2, r2);
=> add(FooClass . pow(x, 2), FooClass . pow(y, 2))
(NB. applyb1 works bottom up, apply1 works top down.
So apply1 has the wrong effect on r2 because r2's output matches r2.)
> I also need to write for Gnu GMP under C++, which has
> some nasty notations.
Yeah, it's quite a disaster, isn't it ... but tell us what you want
and I'll give it a try.
> Moreover i want to do these computations for complex numbers,
> so i have to promote reals to
> complex numbers when they appear in the expressions, etc.
matchdeclare (xx, lambda ([e], atom (e) and featurep (e, real)));
defrule (r3, xx, complex (xx, 0));
declare (a, real);
featurep (a, real);
=> true
featurep (b, real);
=> false
bar : 1 + baz (%pi, %i) + quux (mumble (1), a, b);
applyb1 (bar, r3);
=> quux(mumble(complex(1, 0)), complex(a, 0), b) + baz(complex(%pi,
0), %i) + complex(1, 0)
> So it is very necessary to somewhat analyze the expressions.
Agreed; you should do that using Maxima functions.
Maybe after completing this exercise we will have some rules &
other mogrifications which we can package as a Maxima -> C
or Maxima -> Java conversion function. Just a thought.
HTH
Robert Dodier