[GiNaC-list] Simplifying a hierarchy of rational powers on positive symbols
Richard B. Kreckel
kreckel at ginac.de
Tue Feb 21 09:53:15 CET 2012
Hi!
On 02/18/2012 10:47 PM, DerManu at WorksLikeClockwork.com wrote:
> Consider the following expression:
> (2^(2/3)*x^2)^(3/2)
> where x is positive.
> I'd expect eval() to reduce this to 2*x^3, but it happens only, when
> calling evalf(). However, I'd like other possible parts of the
> expression to stay exact, so evalf() isn't an option.
>
> Here's the code for the above expression:
> possymbol x("x");
> ex e = power( power(2,numeric(2)/numeric(3)) * power(x, 2) ,
> numeric(3)/numeric(2) );
> std::cout << e.eval() << " " << e.evalf() << std::endl; // I know eval
> is redundant, but it adds a dramatic element ;)
>
> Note this situation is somewhat related yet much simpler than Topic [1]
> because we're dealing with purely numeric powers here. Still it seems,
> this kind of simplification is just not wanted. Is that correct? Or is
> there a trick to make it all work easily?
It's not that such a simplification is not wanted. It's just not
implemented (yet?)
Your example involves only products and rational exponents. In this
case, GiNaC could indeed go a little bit further, I suppose, and do the
transformation for you.
In a slightly more general context, however, one might deal with sums.
And then things start getting really, really hairy, even in the absence
of symbols. The question is where to draw the line.
Keep in mind that one crucial requirement for a transformation to be
eligible for automatic .eval() is that it's complexity must be lower
than O(N^2) where N is some suitable measure for the length of the
expression. This is because .eval() is invoked automatically upon input
and we don't want the program to explode on medium-sized input: it would
impede the subsequent use of better suited specialized algorithms.
BTW: In the past, GiNaC has evolved in some tiny steps into the
direction you want. (C.f. commit e34ac03e77644.)
> Would it be a sensible approach to write a map_function functor that
> grabs all powers that have positive muls as base and apply the power to
> all mul ops individually?
Of course!
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
More information about the GiNaC-list
mailing list