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 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 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. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>