You can see course notes on simplification and in particular
Richardson's zero-equivalence algorithm
here
http://inst.eecs.berkeley.edu/~cs282/sp02/lects/13.ppt
also lects/12.ppt might be of interest.
The idea of evaluation is not effective in general, but maybe you don't
want a proof, just a hackish guess.
As long as we are collecting thoughts on the matter...
Here is a function
f(x):= if rationalize(float(x))-rationalize(x)=0 then 0 else 1;
which returns 0 for every number that is either a floating-point number,
or can be exactly represented as a floating-point number, and hence will
return 0 for every random floating-point evaluation point.
But f(x) is 1 almost everywhere. f(1/3)=1 for example.
You can't even tell if a function is defined unless you can prove a
denominator is not zero.
and what about logs etc.
And what if the denominator is infinite?
RJF
Stavros Macrakis wrote:
> Well, here are a few thoughts.
>
> As has been clear since zeroequiv was first thought of (by Joel
> Moses?), it can never be perfect. However, it could be much better
> than it currently is.
>
> For one thing, it could look at a wider range of random values.
> Though analysis tells us that infinitely differentiable functions are
> globally characterized by their local behavior, in practice it would
> be useful to look at values in a wider range -- notably very large
> values.
>
> Zeroequiv would be an excellent application for interval arithmetic,
> but unfortunately we don't have a practical implementation of interval
> arithmetic in Maxima.
>
> The fuzz value should definitely be rethought. It is probably still
> defined using the original PDP-10 values where not only was it 36-bit
> floats (as opposed to the current 72-bit ones), but also pre-IEEE
> floating point and not very good numerical libraries.
>
> Then again, I am not sure who uses it or cares....
>
> -s
>
>
> On Fri, Apr 10, 2009 at 12:57 PM, Rupert Swarbrick
> <rswarbrick at googlemail.com> wrote:
>
>> Have spent some time today looking at zeroequiv and bug 593530. It seems
>> that, as Dieter suggests, zeroequiv is never going to be great: frankly,
>> given anything nontrivial except rational functions, it'll always punt
>> to zeroequiv2, which works by evaluating the expression at a random
>> point in [0,1) and deciding whether it's close to zero.
>>
>> Anyway, since I wrote up a text file as I went through the code working
>> out what it was doing, I thought I'd post it here. The one thing I would
>> suggest changing is to ensure that, given an expression free of the
>> variable, it immediately tries numerical evaluation (since the rest of
>> the algorithm ain't gonna help).
>>
>> I've attached a patch that does this, adds a couple of tests and has the
>> documentation I mentioned.
>>
>> The examples of e.g. sin(x+1/1000)-sin(x) are going to give "zero",
>> since they will get evaluated numerically and then give something
>> smallish. Maybe the 1e-2 fuzz value in the code should be customizable?
>> Or should we change the code to evaluate it with higher precision based
>> on fpprec and then set the fuzz value to depend on that? (I kind of like
>> this idea, since it doesn't add a new control knob, but at least allows
>> someone to try a bit harder).
>>
>> Anyway, I thought I'd send this in case it was of interest to anyone.
>>
>> Rupert
>>
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>>
>>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>