Add a global is_trivial_zero function

[arminstraub]

Some rings have a polymorphic comparison with zero, e.g., comparison in SR can mean 1. "try to prove with certainty" or 2. "check if numeric zero". Other rings may have different features. This ticket implements a global is_trivial_zero that explicity requests the object's is_trivial_zero member if it exists, otherwise checks obj==0.

CC: @nbruin @videlec @mezzarobba

Component: symbolics

Author: Ralf Stephan

Branch/Commit: u/rws/add_a_global_is_trivial_zero_function @ 7241f8e

Issue created by migration from https://trac.sagemath.org/ticket/21201

[rwst]

comment:1

A plan would be in symbolics to use a fast zero comparison like the one in comparison.pyx:mixed order in is_zero and additionally change the expensive symbolic zero comparison (the main code is in __nonzero__, see also #19040) to something being able to return Yes/No/Maybe, which is incompatible with the global boolean is_zero and therefore should have a new name. Having a global is_trivial_zero would fit with this.

[rwst]

Branch: u/rws/add_a_global_is_trivial_zero_function

[rwst]

Commit: 7241f8e

[rwst]

Author: Ralf Stephan

[rwst]

New commits:

7241f8e

21201: global is_trivial_zero

[videlec]

comment:4

I am against such a terrible name in the global namespace that is furthermore almost not specified.

Though it would be good to design a general solution for the different semantics of equality.

[rwst]

comment:5

FYI, about 320 files under src/sage have doctests that, directly or indirectly, call Expression.__nonzero__. A quick glance shows in most cases a simplification/proof of equality is not needed.

[videlec]

comment:6

Replying to @rwst:

FYI, about 320 files under src/sage have doctests that, directly or indirectly, call Expression.__nonzero__. A quick glance shows in most cases a simplification/proof of equality is not needed.

This is a bad measure. And anway, 320 files is 12% of the number of files in the Sage source tree...

[videlec]

comment:7

You aim to introduce a feature that concerns only the symbolic ring. Then simply implement it as a method of SR (or the elements of SR). Ne need to clutter even more the global namespace.

[rwst]

comment:8

So in every case (e.g. in polynomial_element.pyx) the code has to check for expression, and call that member function?

[mezzarobba]

[ticket:21201 Ticket description]:

Some rings have a polymorphic comparison with zero, e.g., comparison in SR can mean 1. "try to prove with certainty" or 2. "check if numeric zero". Other rings may have different features. This ticket implements a global is_trivial_zero that explicity requests the object's is_trivial_zero member if it exists, otherwise checks obj==0.

Just to be sure: what do you mean by "check if numeric zero": check if something seems to be zero based on it numerical evaluation, or check if is syntactically zero? If the latter: yes, this is a very useful feature to have, for many, many types of objects. But in the case of SR, is there any strong reason to have == do more than check for syntactic equality?

[rwst]

comment:10

Replying to @mezzarobba:

Just to be sure: what do you mean by "check if numeric zero": check if something seems to be zero based on it numerical evaluation, or check if is syntactically zero? If the latter: yes, this is a very useful feature to have, for many, many types of objects. But in the case of SR, is there any strong reason to have == do more than check for syntactic equality?

Clearly not but unfortunately bool() with symbolic arguments does more by default. Please see https://trac.sagemath.org/wiki/symbolics/nonzero for a summary. The goal is to design a better interface to the existing functionality.

[mezzarobba]

comment:11

Replying to @rwst:

Clearly not but unfortunately bool() with symbolic arguments does more by default.

Well, IMO (though I haven't really thought it through):

• bool(expr) should return False iff expr is exactly SR(0), without any simplification, even trivial ones,
• expr == 0 should return True when bool(expr) returns False, and may return True in some cases where trivial simplifications show that expr is zero, but shouldn't perform any nontrivial computation (I would say simplifying x - x to zero is okay, attempting to expand a polynomial is not—but this is of course debatable),
• there should be methods expr.foo() that attempt to prove that expr is zero (e.g. by simplifying it), that expr is nonzero (e.g. by substituting values for the variable and performing interval evaluation), that expr could be zero (for some values of the variables), and probably more. At least some variants of these methods should take into account assumptions on the variables. I'm not sure what exact set of such methods would be needed, whether they should return plain booleans or use Unknown, nor how they should be named (and in particular, whether using the names is_zero() and is_nonzero() would conflict with their semantics elsewhere in Sage).

[rwst]

comment:12

That is pretty much in line with #19162, and I find William Stein's suggestion of expr.is_zero(simplify=False/True) an especially good idea.

[rwst]

comment:13

The original ticket will not be implemented.

[videlec]

comment:14

closing positively reviewed duplicates