A fast way to check if an expression is zero is important in many places, see for example comment:15:ticket:11143. We should put the numerical check mentioned there in a method (_is_numerically_zero()) of symbolic expressions (sage.symbolic.expression.Expression).

Change History (26)

I attached a patch providing a function which doesn't do much. It should eventually check (reasonably quickly I hope) if expressions like (pi-1)*pi - (pi-2)*pi - pi) or e^I^pi +1 are zero. This function can be used to provide a template for implementing #11143 while someone tries to improve it.

So what does this exactly check? Just if something is a numeric Ginac object that Ginac knows is zero? So we won't get any false positives? That is my main concern, for instance with #1173 or #11143 - we wouldn't want mathematical incorrectness to get a speedup.

I'm puzzled about this ticket. Why doesn't the is_zero method suffice? As said by Karl-Dieter,
for general expressions the problem is undecidable, thus if you want to check expressions that
*reduce* to zero, the name of the method should reflect the fact that there could be false
negatives.

I'm puzzled about this ticket. Why doesn't the is_zero method suffice? As said by Karl-Dieter,
for general expressions the problem is undecidable, thus if you want to check expressions that
*reduce* to zero, the name of the method should reflect the fact that there could be false
negatives.

Hi Paul, I wanted to ask you about this in Warwick. I got caught up in the linear algebra stuff and this slipped my mind.

is_zero() usually ends up calling maxima, which is very slow especially in the context of automatic evaluation of symbolic functions.

At the moment, many symbolic functions (see sage/functions/generalized.py for example) use code similar to the following to test if an argument is zero within a reasonable time: (BTW, this code should not initialize CIF on every call.)

The reason for this ticket was to move this to a separate function to avoid code duplication. If this function can detect pi + (pi - 1)*pi - pi^2 == 0 or (pi - 1)*x - pi*x + x == 0 it would be even better. In this context, false negatives are not a problem. We should just avoid false positives. It's also OK if this test is not purely numeric. Any suggestions for a better name for this function is also welcome of course.

The _is_numerically_zero() has only been used in a few new symbolic functions, we haven't tested replacing the heavily duplicated test code that Burcin is talking about with this new method to see if many doctests fail. My impression is that it is useful to have such a method for automatic simplifications like e.g. erf(0) should return 0 not erf(0), for instance to address #8983.

After playing around with ComplexIntervalField, different precisions and symbolic expressions, I finally realized that they cannot perform magic and detect zero. :)

attachment:trac_11513-is_trivally_zero.patch​ implements a method is_trivially_zero() instead. This is just a wrapper around pynac's is_zero() method, which amounts to the exact integer or real/complex zero check Paul suggested.

Can we review this quickly and turn to another ticket that requires magic: #9953?

the patch looks good to me. Since this a new function, and it is not used anywhere yet, the
doctests should still run, but I will try to be sure. Just a minor point: I'd prefer as name
is_trivial_zero which is simpler.