Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behaviour of symbolic zero. #8555

Open
sagetrac-lfousse mannequin opened this issue Mar 17, 2010 · 6 comments
Open

Unexpected behaviour of symbolic zero. #8555

sagetrac-lfousse mannequin opened this issue Mar 17, 2010 · 6 comments

Comments

@sagetrac-lfousse
Copy link
Mannequin

sagetrac-lfousse mannequin commented Mar 17, 2010

Consider the following commands:

sage: x = PolynomialRing(RealField(42), 'x', 2).gens() 
sage: x[0]^2 - x[1]^2 == SR(1)
x0^2 - x1^2 == 1
sage: x[0]^2 - x[1]^2 == SR(0)
False

It seems the symbolic zero is behaving in an unexpected way.

CC: @sagetrac-jakobkroeker

Component: symbolics

Author: André Apitzsch

Branch/Commit: u/aapitzsch/ticket/8555 @ c79c0fb

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

@sagetrac-lfousse sagetrac-lfousse mannequin added c: symbolics and removed c: algebra labels Mar 17, 2010
@sagetrac-lfousse sagetrac-lfousse mannequin assigned burcin and unassigned aghitza Mar 17, 2010
@a-andre
Copy link

a-andre commented Jul 26, 2014

Commit: c79c0fb

@a-andre
Copy link

a-andre commented Jul 26, 2014

comment:2

Since we have

sage: SR(0) == x[0]^2 - x[1]^2
0  == x[0]^2 - x[1]^2

the patch changes

sage: x[0]^2 - x[1]^2 == SR(0)
False

to

sage: x[0]^2 - x[1]^2 == SR(0)
 x[0]^2 - x[1]^2 == 0

The same applies to !=.


New commits:

c79c0fbfix unexpected behaviour of symbolic zero

@a-andre
Copy link

a-andre commented Jul 26, 2014

Author: André Apitzsch

@a-andre
Copy link

a-andre commented Jul 26, 2014

Branch: u/aapitzsch/ticket/8555

@nbruin
Copy link
Contributor

nbruin commented Jul 26, 2014

comment:3

Perhaps it's better to be a bit more selective than just avoiding the zero shortcut completely. It's only SR(0) that has this funny behaviour. All other zeros should be fine. So the test should probably be something like

    if not isinstance(right, sage.symbolic.expression.Expression) and right == 0:
        return bool(self._MPolynomial_element__element)

Note the chance to the if body.
This return value evaluates slightly faster when self is in fact 0 and a lot faster if self is nonzero (I suspect it kicks down to checking if self._MPolynomial_element__element.__len__() is 0, but does so on CPython slot level, so saves quite a bit of lookup).

It's of course nice to try and make symbolic entities work consistently with MPolynomial, but interacting with SR is not the main purpose of MPolynomial, so you should make sure that measures undertaken for it do not affect other use cases.

I don't have an immediate answer on what the best way is to make available the symbol sage.symbolic.expression.Expression (or what the best test is determine reliably and cheaply whether right is an element of SR). One way is of course to just import sage.symbolic.expression, but it's a little unfortunate to create an apparent dependence (even if that's a circular import, it should be fine, though). Doing the import in the method is not an option.

@videlec
Copy link
Contributor

videlec commented Feb 1, 2015

comment:4

Hello,

Peter: On the other hand, fast comparisons with 0 should be done within __nonzero__ and called via bool(P) or possibly P.is_zero() that indirectly calls the former.

André: Could you check that __nonzero__ is implemented and modify the appropriate part of the code which uses P == 0 or P != 0?

Vincent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants