#12967: bugs in comparisons between constants, wrapped pyobjects, infinity
-------------------------------------+-------------------------------------
Reporter: dkrenn | Owner: burcin
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.6
Component: symbolics | Resolution:
Keywords: compare pi | Merged in:
infinity bool | Reviewers: Karl-Dieter Crisman
Authors: Travis Scrimshaw, | Work issues:
Ralf Stephan | Commit:
Report Upstream: N/A | c5845f6b18d582807dafaaf60ad6a5c8017173f3
Branch: u/rws/12967-2 | Stopgaps:
Dependencies: #17984 |
-------------------------------------+-------------------------------------
Comment (by mmezzarobba):
Replying to [comment:53 pbruin]:
> Not at all; I often find that a good first step towards fundamentally
fixing a bug is trying to ''remove'' hacks that someone else put in to
make a specific example work.
I strongly agree with that. Making specific examples work with no regard
for global consistency usually means introducing bugs, not fixing them.
> > You can only make it easier (but by a huge amount) with good design
and a well thought out model. Since no good model presents itself and
delegating the task to the item is good design this would be an ansatz.
> I disagree that no good model presents itself; defining `x in P` as
`bool(P(x) == x)` seems like a good programming model to me, since it is
simple and predictable.
I tend to agree. Note however that the current definition is more along
the lines of `parent(x) == P or P(x) == x`, which may not be the same
(think of intervals or objects that may not compare as equal to copies of
themselves).
> The more I think about it, the more the fundamental problem does not
seem to be membership testing, but ''comparison'' between real numbers
defined in different approximations of the real numbers. Do we want
`RR(sqrt(2))` to be equal to `SR(sqrt(2))` or not? And what about
`RR(1/3)` and `QQ(1/3)`?
As I repeat on every possible occasion, comparisons in sage are broken in
more ways than I can count. One of the fundamental reasons IMHO is that
`==` confuses at least two kinds of comparisons (in addition to `is`),
call them ''strict'' comparisons and ''semantic'' comparisons. Under
''strict'' equality, for instance, elements of different parents would
always compare as unequal, and elements of a parent with no normal form
would typically compare as equal only if they have the same syntactic
representation. ''Semantic'' equality however could attempt coercing the
elements in a common parent much like `==` currently does. (I believe that
`==` should refer to the ''strict'' equality since, among other things,
that would avoid many of the problems with hashing. But I know that many
people disagree.)
Clearly we are talking about ''semantic'' equality here, but I believe
making the previous distinction (at least conceptually) helps separating
the issues. Now about your examples: with the current model with a single
equality predicate, my answer is **NOOO!!! ** in both cases. With a
separate ''strict'' equality, it is less clear-cut, but intuitively I
would still expect both results to be `False`.
--
Ticket URL: <http://trac.sagemath.org/ticket/12967#comment:55>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
