Opened 3 years ago

Closed 12 months ago

#21201 closed enhancement (wontfix)

Add a global is_trivial_zero function

Reported by: arminstraub Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: symbolics Keywords:
Cc: nbruin, vdelecroix, mmezzarobba Merged in:
Authors: Ralf Stephan Reviewers:
Report Upstream: N/A Work issues:
Branch: u/rws/add_a_global_is_trivial_zero_function (Commits) Commit: 7241f8e926fc2349c2d62e0911975db4f75f46db
Dependencies: Stopgaps:

Description (last modified by rws)

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.

Change History (14)

comment:1 Changed 3 years ago by rws

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.

comment:2 Changed 14 months ago by rws

  • Branch set to u/rws/add_a_global_is_trivial_zero_function

comment:3 Changed 14 months ago by rws

  • Authors set to Ralf Stephan
  • Cc nbruin vdelecroix added
  • Commit set to 7241f8e926fc2349c2d62e0911975db4f75f46db
  • Description modified (diff)
  • Milestone set to sage-8.2
  • Status changed from new to needs_review

New commits:

7241f8e21201: global is_trivial_zero

comment:4 Changed 14 months ago by vdelecroix

  • Cc mmezzarobba added

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.

comment:5 follow-up: Changed 14 months ago by rws

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.

comment:6 in reply to: ↑ 5 Changed 14 months ago by vdelecroix

Replying to rws:

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...

comment:7 Changed 14 months ago by vdelecroix

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.

comment:8 Changed 14 months ago by rws

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

comment:9 in reply to: ↑ description ; follow-up: Changed 14 months ago by mmezzarobba

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?

comment:10 in reply to: ↑ 9 ; follow-up: Changed 14 months ago by rws

Replying to mmezzarobba:

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.

comment:11 in reply to: ↑ 10 Changed 14 months ago by mmezzarobba

Replying to rws:

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).

comment:12 Changed 14 months ago by rws

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.

comment:13 Changed 14 months ago by rws

  • Milestone changed from sage-8.2 to sage-duplicate/invalid/wontfix
  • Status changed from needs_review to positive_review

The original ticket will not be implemented.

comment:14 Changed 12 months ago by vdelecroix

  • Resolution set to wontfix
  • Status changed from positive_review to closed

closing positively reviewed duplicates

Note: See TracTickets for help on using tickets.