Roots of unity

Richard B. Kreckel kreckel at
Mon Jan 21 13:33:09 CET 2002

On Sun, 20 Jan 2002, Bob McElrath wrote:
> You wouldn't need it to be accurate 100% of the time.  Like some other
> functions in the library, is_negative should be true if "it can be determined
> that..." and false should mean either false or it cannot be determined.
> In using this for simplifications and rearrangements, it only means that a
> particular simplification wouldn't be applied.

Right.  The logic "boolean true is a guarantee, boolean false may mean
unable to deduce" is already implicitly anchored in a lot of places since
that seems to be the only sensible way to tackle such things.

As you noticed, the infrastructure for this is already partly in
place.  What you would need to do is attach some assumptions to symbols
and then try to make such information propagate through arbitrary
expressions.  Right now they are all assumed to stand for any complex

Knowing that symbol `a' is positive would help other kinds of computation,
for instance series(log(a*x),x==0,2); need not be inert any more.  If I am
not mistaken log_evalf() woulnd't even have to be touched.

Care to suggest a catalog of useful properties along with an analysis how
orthogonal they are and provide an implementation?

> I wonder if "cheating" and using evalf would get you into trouble?  i.e.
>     evalf(a-b) < 0

No, this is not a programmatic way to analyze such things.  Even if
implemented properly it will bring you into rounding hell.

Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>

More information about the GiNaC-list mailing list