Why does "==" not return True or False?
Simon King
i met the following bug/feature:
sage: ((-x^4-1)/(x^2)) == ((x^4+1)/((-1)*x^2))
(-x^4 - 1)/x^2 == (-x^4 - 1)/x^2
That's to say, the expressions are displayed in the same canonical
form, but "==" does not return True.
Is this worth a ticket?
----------------
Another potential bug:
sage: Ring=PolynomialRing(QQ,'x')
sage: x=Ring('x')
sage: ((-x^4-1)/(x^2))
(-x^4 - 1)/x^2
sage: ((x^4+1)/((-1)*x^2))
(x^4 + 1)/-x^2
Why are these expressions not turned into a canonical form, in
contrast to above? And how can i achieve such canonical form?
Is this also worth a ticket?
sage: ((-x^4-1)/(x^2)) == ((x^4+1)/((-1)*x^2))
True
So, at least "==" works as it should.
Yours sincerely
Simon
John Cremona
In your first example, where you have not defined x, it is treated as
a symbol and the expressions you create using x are purely symbolic;
in fact they are objects within the underlying maxima system. In this
system, "==" is used to create equations, not to test equality. And
in that system, certainl simplifications are done automatically.
In your second example, you are creating a specific ring containing an
element x, namely the ring of polynomials on one variable x over QQ.
Your expressions now live in that ring (or its function field). This
is a Sage ring, and == is a boolean test.
I agree that this is confusing. Sage is trying to cater
simultaneously for different kinds of users, including those who
expect a symbolic system like maxima and those who expect to have to
define rings "properly" as in Magma. The latter can result is very
much faster code.
I hope this helps -- and it is likely that a more definitive answer
will come from others on the Sage development team.
John
--
John Cremona
Mike Hansen
> That's to say, the expressions are displayed in the same canonical
> form, but "==" does not return True.
This is the desired behavior in Sage with symbolic objects -- it
returns the equation you specified. You can get a Boolean with
bool().
sage: eq = ((-x^4-1)/(x^2)) == ((x^4+1)/((-1)*x^2)); eq
(-x^4 - 1)/x^2 == (-x^4 - 1)/x^2
sage: bool(eq)
True
sage: if eq:
....: print "This is True."
....:
This is True.
> sage: Ring=PolynomialRing(QQ,'x')
> sage: x=Ring('x')
> sage: ((-x^4-1)/(x^2))
> (-x^4 - 1)/x^2
> sage: ((x^4+1)/((-1)*x^2))
> (x^4 + 1)/-x^2
> Why are these expressions not turned into a canonical form, in
> contrast to above? And how can i achieve such canonical form?
The objects you are working with here are elements of a generic
implementation of fraction fields. I'm actually dealing with this
issue now since I'm doing some work with rational functions. For
Frac(QQ['x']), I'm just clearing denominators and removing common
non-unit integers in order to keep coefficients "small". But, this is
just a choice for a canonical form. Magma, for example, makes it so
that the denominator is always monic. No such choice has been made in
Sage primarily because it (nor the best way to implement it) has not
been discussed.
--Mike
P.S. The "Sage way" to make your ring would probably be the following:
sage: R.<x> = QQ[]
sage: R
Univariate Polynomial Ring in x over Rational Field
sage: x.parent()
Univariate Polynomial Ring in x over Rational Field
or in pure Python:
sage: R = QQ['x']; x = R.gen()
Simon King
On 8 Feb., 10:40, "John Cremona" <john.crem...@gmail.com> wrote:
> In your first example, where you have not defined x, ...
... but it is pre-defined, and explicitly saying "var('x')" has the
same effect.
> In this
> system, "==" is used to create equations, not to test equality.
My personal opinion is: When i say "==" in Sage then i expect a
consistent behaviour, hence, a test for equality. Certainly the __eq__
method can do whatever the programmer wants, but it would be good
style to make it consistent with the rest of Sage.
Working in Sage, i do believe that Sage's conventions should overrule
the conventions of any sub-system. Hence, if i want "==" to be
interpreted in the Maxima-way, i would express that wish explicitly,
say, by
maxima('x==x')
However, i do understand that this would hardly be possible to change
now.
By the way, i just tested "maxima('x==x')", and Sage *freezes*!
Why?
> In your second example, you are creating a specific ring containing an
> element x, namely the ring of polynomials on one variable x over QQ.
for polynomials over QQ? Note that simplify(((x^4+1)/((-1)*x^2)))
again returns (x^4 + 1)/-x^2.
Thank you for your answer, that made me understand the reason for the
different behaviour of "==" (although i don't like it).
Now i would like to understand why "maxima('x==x')" is so difficult
for Sage. It doesn't give an error, it simply hangs.
Yours sincerely
Simon
Simon King
On 8 Feb., 10:58, "Mike Hansen" <mhan...@gmail.com> wrote:
> This is the desired behavior in Sage with symbolic objects -- it
> returns the equation you specified. You can get a Boolean with
> bool().
evaluation is needed.
I was just playing around with maxima's equations and spotted another
thing that i find inconsistent.
You and John explained that "x==x" returns an equation since the
underlying maxima system does.
So, why does maxima('x')==maxima('x') return True?
And why maxima('x==x') freezes?
<snip>
> just a choice for a canonical form. Magma, for example, makes it so
> that the denominator is always monic. No such choice has been made in
> Sage primarily because it (nor the best way to implement it) has not
> been discussed.
explicitly change an element of the fraction field of QQ[x] into a
canonical form (i.e., two elements are equal iff the canonical forms
are identic)? Note that "simplify" doesn't do it.
Yours
Simon
Mike Hansen
> You and John explained that "x==x" returns an equation since the
> underlying maxima system does.
> So, why does maxima('x')==maxima('x') return True?
> And why maxima('x==x') freezes?
When John said that the underlying system (maxima) uses that
construction, he didn't mean it _literally_. "x==x" isn't even valid
Maxima syntax -- it gives a syntax error. Sage is having trouble
detecting it for some reason so that is indeed a bug, but probably not
what you were thinking of. I've made a ticket for this at
http://trac.sagemath.org/sage_trac/ticket/2109 .
If you have a better proposal for handling symbolic equations, I'm
sure people would be more than willing to listen to it. While I don't
really use the symbolic stuff, I personally think the current way of
handling things is very natural and quite usable.
> Automatic simplification is one thing. But is there an explicit way to
> explicitly change an element of the fraction field of QQ[x] into a
> canonical form (i.e., two elements are equal iff the canonical forms
> are identic)? Note that "simplify" doesn't do it.
Like I mentioned in my previous email, no such canonical form has been
decided on. (If you look at the implementation for equality testing
in that ring, it cross multiplies numerators and denominators and
check for equality in QQ['x'].)
--Mike
Bobby Moretti
>
> Dear John,
>
> On 8 Feb., 10:40, "John Cremona" <john.crem...@gmail.com> wrote:
> > In this
> > system, "==" is used to create equations, not to test equality.
>
> That's nasty!
>
> My personal opinion is: When i say "==" in Sage then i expect a
> consistent behaviour, hence, a test for equality. Certainly the __eq__
> method can do whatever the programmer wants, but it would be good
> style to make it consistent with the rest of Sage.
>
> Working in Sage, i do believe that Sage's conventions should overrule
> the conventions of any sub-system. Hence, if i want "==" to be
> interpreted in the Maxima-way, i would express that wish explicitly,
> say, by
> maxima('x==x')
>
> However, i do understand that this would hardly be possible to change
> now.
Simon,
Understandably, things like this are confusing. As John said, the
problem is that Sage is trying to cater to different audiences. A more
casual user such as a calculus student will want an easy way to define
symbolic equations, and using the various boolean testing operators
with symbolic expressions seems like the natural thing to do.
Although in some sense it is true that the Sage symbolics package
provides a thin layer over maxima, it is still meant to provide a
general interface for symbolic computation, abstracted *from* maxima.
So the notation x^2 == 2 has little to do with maxima, and more with
the architecture that we chose for general purpose symbolics.
It is unlikely users at the research level will want to use these
symbolic expressions at all in their code, since they favor optimized
and specialized code that only works for their application. In some
sense I am glad that the behavior is quite different since that way
there is less mystery as to what package is being used.
So when you create a polynomial ring, for example, you are entereting
in a much more structured realm than the Sage symbolics package, and
should expect rather different and more specialized behavior.
I hope that explains some of our reasoning on this somewhat confusing
behavior...
-Bobby
--
Bobby Moretti
mor...@u.washington.edu
Jurgis Pralgauskis
> > > In this
> > > system, "==" is used to create equations, not to test equality.
> >
> > That's nasty!
for me that also seems potential source of confusion
maybe "===" would be better for equations?
as much as I remember, maxima uses "=", so "==" also doesn't help
maxima users a lot..
Simon King
On Feb 9, 8:44 am, "Jurgis Pralgauskis" <jurgis.pralgaus...@gmail.com>
wrote:
<snip>
triple equals sign usually denotes identity, whereas the meaning of a
single or a double equals sign is ambiguous. Hence, "A===B" should
either be a synonym for "A is B", or it would introduce another
confusion.
> as much as I remember, maxima uses "=", so "==" also doesn't help
> maxima users a lot..
before...) then i really don't see why "==" in some context creates an
equation. Except that now it would likely be difficult to change,
since some code may depend on it.
Cheers
Simon
Bobby Moretti
When you make two *purely* symbolic expressions, and compare them, is
it unreasonable for this to create a symbolic equation? What is a more
natural way to create symbolic equations and inequalities? We chose
this since triple equals seemed ridiculous. Double equals existed in
python so no preparsing was required. It did not even break anything
like hash table lookups since we could override __nonzero__.
If not ==, what would you propose for creating symbolic expression
objects? The other obvious choice is eq(f, g), but I think that this
is inferior since it is much harder to guess.
sage: solve(x^2 - 2 == 0, x)
as opposed to
sage: solve(eq(x^2 -2, 0), x)
The first is totally clear, and is more similar to mathematical notation...
Ondrej Certik
> > before...) then i really don't see why "==" in some context creates an
> > equation. Except that now it would likely be difficult to change,
> > since some code may depend on it.
>
> When you make two *purely* symbolic expressions, and compare them, is
> it unreasonable for this to create a symbolic equation? What is a more
> natural way to create symbolic equations and inequalities? We chose
> this since triple equals seemed ridiculous. Double equals existed in
> python so no preparsing was required. It did not even break anything
> like hash table lookups since we could override __nonzero__.
>
> If not ==, what would you propose for creating symbolic expression
> objects? The other obvious choice is eq(f, g), but I think that this
> is inferior since it is much harder to guess.
Let me chime in this thread as well. Right know we are dealing with
the exact same issue in SymPy. Actually we are dealing with this for
months already. :)
The == returning an equation *is* confusing to me. However, we
thought, ok, it's a nice syntax, let's use it, so we use it in SymPy
too. But then
there is a speed issue. If you want to read all the deatils, go here:
http://code.google.com/p/sympy/issues/detail?id=135
In short, in Python, the == operator is used a lot internally, so
returning a class instead of True/False does slow things down. Some of
the problems can be overcomed, some not. So, in SymPy, we want to do
things easily, pythonic and fast too. Given these constraints, it's
not at all clear, which way to choose for ==, there are good arguments
for both possibilities.
You may argument for example, that you want to do things
mathematically correct in Sage (whatever it means). But speed is
important too, you can search archives to find some examples, where
Sage+maxima is currently slower than even pure python SymPy (and sympy
can still be sped up by at least a factor of 10x while staying in pure
Python), imho all due to conversions between Sage and maxima etc. It
can imho be improved to some extent, but I think the right solution is
to do it in Python (+ Cython), which is what we are trying, but this
has the disadvantage, that it is not as robust yet as maxima, which
has decades of testing behind it.
Anyway, I am not giving any answer to this, as I don't know the answer.
CCing sage-devel, as I think this is a design-development question.
Ondrej
Simon King
On Feb 9, 12:26 pm, "Bobby Moretti" <bobmore...@gmail.com> wrote:
> We chose this since triple equals seemed ridiculous.
it is a reasonable choice.
Certainly i agree that a change would be destructive,
and certainly for a mathematician
sage: solve(x^2 - 2 = 0, x)
is very intuitive.
Confusing is it only for those who did programming before. In
solve(x^2 - 2 == 0, x), i would guess that the "equation" is first
evaluated, and it becomes solve(False,x).
Is it technically possible that Sage generally interpretes "==" as a
test for equivalence, *except* if it is used inside "solve"?
> If not ==, what would you propose for creating symbolic expression
> objects? The other obvious choice is eq(f, g), but I think that this
> is inferior since it is much harder to guess.
So, if one really wants an equation as an object, why not eq(f,g)?
And if one wants to use solve, why not in that way:
sage: solve(x^2,'=',2,x) # solves x^2=2
sage: solve(x^2,'<',2,x) # solves x^2<2
etc.
Or:
sage: solve(x^2-2,x)
This would solve x^2-2=0, and i think there are CAS who have that
syntax in a solve command!
Yours
Simon
Ondrej Certik
Exactly, this is my philosophy too. But I understand other people may
have different opinions.
Ondrej
Jurgis Pralgauskis
> > If not ==, what would you propose for creating symbolic expression
> > objects? The other obvious choice is eq(f, g), but I think that this
> > is inferior since it is much harder to guess.
>
> How often does one need an equation *outside solve*? I never did!
> So, if one really wants an equation as an object, why not eq(f,g)?
>
> And if one wants to use solve, why not in that way:
> sage: solve(x^2,'=',2,x) # solves x^2=2
> sage: solve(x^2,'<',2,x) # solves x^2<2
well, inequalities would also have this kind of confusion (as Simon
described in the first mail)..
http://groups.google.com/group/sage-support/t/dc9a94da8d930999
so probably more general markup way should be found for symbolic
equations/inequalities or left as it is
maybe some `==, `<, `> notation or other symbol instead of
'== '< '>
_== _< _>
' would make most sense in symbolic stuff as it is usually used
with "symbols" :),
but don't know if interpreter won't get confused
ps: can SAGE solve inequality (as the one here)
http://www.sagemath.org/doc/html/ref/module-sage.calculus.wester.html sais NO
(what is so difficult about inequalities - at least the school level ones)
Jason Grout
I am working to eventually incorporate QEPCAD into Sage, which would
allow us to simplify (and solve) inequalities and statements involving
quantifiers. Right now there are licensing and build issues that we are
working through.
Jason