[Maxima] Zeroequiv and sf bug 593530
macrakis at alum.mit.edu
Fri Apr 10 12:25:53 CDT 2009
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
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....
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.
> Maxima mailing list
> Maxima at math.utexas.edu
More information about the Maxima