[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