Roots of unity

[Bob McElrath]

Richard B. Kreckel [kreckel at zino.physik.uni-mainz.de] wrote:
> Hi,
> 
> On Sun, 20 Jan 2002, Hans Peter Würmli wrote:
> > leadcoefficient*(x-x1)*(x-x2)*(x-x3). To take an example: 
> > 
> > p(x) = 1 + x + x^3
> > 
> > Reassembling p from the roots and expanding produces:
> > 
> > p(x) = 1/2+x+x^3+(-27/2+3/2*sqrt(93))^(-1)-1/18*sqrt(93)
> > 
> > which is correct, if one simplifies 1/2+(-27/2+3/2*sqrt(93))^(-1)-1/18*sqrt(93) to 1
> 
> This is already way cool, isn't it?  But, to "simplify" is not
> well-defined.  Such computations should not be done automatically at the
> level of the anonymous avaluator (i.e. classwhatever::eval()).
> 
> This does not mean that it doesn't fit into the library, per se.  In
> Maple, you may have noticed that `simplify' gets the job done, but what
> really is being called is the function `radsimp'.  We simply haven't
> looked at this yet because we don't need it in our computations so I see
> little hope that Cebix or me is going to do this.  If somebody else wants
> to, patches that implement such a method/function would be welcome.

What I see as needed in order to write some simplification routines are methods
for the ex class like there are in the numeric class:
    is_real, is_integer, operator<, etc...
And an assume() functionality to create symbols that are reals, integers, etc.
So that someone who wants to write some kind of simplification routine can do
so.  I was surprised to find that an expression involving entirely numeric's
cannot be compared with relational operators (because, in general, an ex cannot
be compared with relational operators).  That is:
    > is(-1/2-sqrt(2/9)<0);
    0
This is something that should be straightforwardly determinable, if you had an
is_real and operator< for the ex class.  Then if the above expression appears
as a subexpression in something larger, you can make simplifications
appropriate for reals.  The same kind of comparisons could be done for
expressions involving symbols, similar to Maple's assume() functionality:
    symbol x("x");
    assume(x, real);    // prototype: void assume(ex& x, info_flags fl = -1);
    assume(x>0);
    if(-x^2-x-10 < 0) { cout << "polynomial is negative" << endl; }

I agree with you in general on not having automatic simplifications done for
eval()...But something like the above would help people write custom
simplifications.  I personally would like a library of fine-grained
"simplification" routines to rearrange expressions according to fine-grained
rules.  (i.e. put radicals in the numerator, combine logs, etc...)

The other thing that is needed is for normal() to be able to apply enough
transformations to tell that your simplified expression is the same as the
original.  Already I have run into expressions that after some transformations,
they cannot be compared with the original expression.  As you mention this may
not be possible.  But Maple seems to do it somehow (I often use
if(simplify(EX-newEX)=0)...  as a check -- it puts things in some kind of
canonical form).

Cheers,
-- Bob

Bob McElrath (rsmcelrath at students.wisc.edu) 
Univ. of Wisconsin at Madison, Department of Physics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20020120/e39e8cde/attachment.pgp