Roots of unity

Bob McElrath mcelrath at draal.physics.wisc.edu
Mon Jan 21 16:41:21 CET 2002


Richard B. Kreckel [kreckel at zino.physik.uni-mainz.de] wrote:
> 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
> number.
> 
> 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'll think about it.  This is going to have to become a "spare-time" project.
:(  I had hoped to use GiNaC for some of my physics analysis, but for the
project I'm working on now it's just too much work.  (Maple is easier)  Maybe
for the next one.  How is xloops coming?  ;)

The elements of class info_flags in flags.h would be a good starting point (the
ones answered by class numeric).  Though "nonpositive" seems to be missing.
Tests involving relational operators could subtract the lhs and rhs and use one
of {positive, negative, ...}.  Zero will be very hard to test for unless
.normal() becomes much more powerful.

Maple has a number of others properties:
    RealRange(a,b)
    imaginary
    irrational
    composite       (non-prime integer)
and a lot of assumptions for matrices and functionals.  Maple also has
references in the "assume" help page: ;)
    ``An Algebra of Properties'' by Trudy Weibel and Gaston Gonnet, Proceedings
        of the ISSAC-91 conference, Bonn July 1991, pp 352-359
    ``An assume facility for CAS with a sample implementation for Maple'' by
        Trudy Weibel and Gaston Gonnet, Conference presentation at DISCO '92,
        Bath, England, April 14, 1992.
    ``Simplification and the Assume Facility'', by Robert Corless and Michael
        Monagan, Maple Technical Newsletter, Volume 1, Number 1, Birkhaeuser,
        1994.

> > 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.

Yes, true.  But we have an artibrary-precision arithmetic engine handy...  If
you could algorithmically determine how many digits would be required to
accurately represent each subexpression...

It still seems like cheating.  I'm sure there's many subtleties I don't see
right now.

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/20020121/a54434ed/attachment.pgp


More information about the GiNaC-list mailing list