Opened 10 years ago

Last modified 5 years ago

#8555 needs_work defect

Unexpected behaviour of symbolic zero.

Reported by: lfousse Owned by: burcin
Priority: major Milestone:
Component: symbolics Keywords:
Cc: jakobkroeker Merged in:
Authors: André Apitzsch Reviewers:
Report Upstream: N/A Work issues:
Branch: u/aapitzsch/ticket/8555 (Commits) Commit: c79c0fb678fb6e7f27a966ce7fbadfae258aa3c0
Dependencies: Stopgaps:

Description

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.

Change History (5)

comment:1 Changed 10 years ago by lfousse

  • Component changed from algebra to symbolics
  • Owner changed from AlexGhitza to burcin

comment:2 Changed 5 years ago by aapitzsch

  • Authors set to André Apitzsch
  • Branch set to u/aapitzsch/ticket/8555
  • Commit set to c79c0fb678fb6e7f27a966ce7fbadfae258aa3c0
  • Status changed from new to needs_review

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

comment:3 Changed 5 years ago by nbruin

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.

comment:4 Changed 5 years ago by vdelecroix

  • Status changed from needs_review to needs_work

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

comment:5 Changed 5 years ago by jakobkroeker

  • Cc jakobkroeker added
Note: See TracTickets for help on using tickets.