bug in == operator?

[David Goldberg]

This is in SageMath Version 6.6, Release Date: 2015-04-14 running on a MacBook.  The following lines print 'equal', even though m and m1 do not appear equal to me!

m=540579833922455191419978421211010409605356811833049025*sqrt(1/2)

m1=382247666339265723780973363167714496025733124557617743

if m == m1:

print "equal"

[Jan Groenewald]

Hi

They do look equal:

sage: m.n()

3.82247666339266e53

sage: m1.n()

3.82247666339266e53

Regards,

Jan

--
You received this message because you are subscribed to the Google Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

--

  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^ 

[Nathann Cohen]

This is in SageMath Version 6.6, Release Date: 2015-04-14 running on a MacBook.  The following lines print 'equal', even though m and m1 do not appear equal to me!

It seems that this equality is an equality over 'double' floats. So not all digits of your numbers are taken into account.

Is there a way to force a more exact equality test?

Nathann

 

[Nathann Cohen]

> Is there a way to force a more exact equality test?

It works "as intended" over QQbar:

sage: QQbar(m) == QQbar(m1)
False

Nathann

[John Cremona]

Since m1.nbits() is 178, work to higher precision:

sage: R = RealField(200)

sage: R(m)==R(m1)

False

sage: R(m)-R(m1)

0.89272832870483398437500000000000000000000000000000000000000

This seems to be what is wanted.  I agree that it is bad that m==m1 gives True: m is in the Symbolic Ring (check m.parent()) while m1 is an Integer, and when you ask whether they are equal they are pushed into a common place where this can be tested, which looks like the default real field (only 53 bits).  Even if one sets d=m-m1, so that d is a single element of SR which is certainly not the same as SR(0):

sage: d = m-m1

sage: d.parent()

Symbolic Ring

sage: d

540579833922455191419978421211010409605356811833049025*sqrt(1/2) - 382247666339265723780973363167714496025733124557617743

we find the bizzarre conclusion

sage: d.is_zero()

True

showing that "being zero" in SR is a peculiar concept indeed.

John

PS Testing over QQbar certainly does give False, as it would for m*sqrt(1/2) and n for any pair of integers (m,n) not (0,0), since sqrt(2) is irrational!

Nathann

[Nathann Cohen]

> PS Testing over QQbar certainly does give False, as it would for m*sqrt(1/2)
> and n for any pair of integers (m,n) not (0,0), since sqrt(2) is irrational!

Wouldn't it be better to compare 'exact types' in an exact ring? Here
we compare two exact types in a non-exact field.

Nathann

[Simon King]

Hi all,

No, in this example we compare one exact type and one non-exact type!

One of the arguments lives in the Symbolic Ring, which is not an exact ring:
sage: SR
Symbolic Ring
sage: SR.is_exact()
False

By coercion, the comparison of the integer m1 with the symbolic
expression m below is done after coercion to the symbolic ring:
sage: cm = get_coercion_model()
sage: m=540579833922455191419978421211010409605356811833049025*sqrt(1/2)
sage: m1=382247666339265723780973363167714496025733124557617743
sage: cm.explain(m.parent(), m1.parent(), operator.eq)
Coercion on right operand via
Conversion map:
From: Integer Ring
To: Symbolic Ring
Arithmetic performed after coercions.
Result lives in Symbolic Ring
Symbolic Ring

So, if there is anything to fix then it is how the symbolic ring deals
with exact algebraic data. Here, there is a natural interpretation of m
as an element of QQbar. So, the symbolic ring *could* compare the
symbolic data after pushing them to QQbar:

sage: QQbar(m) == QQbar(m1)
False

However, I don't know if there is an easy way to teach the symbolic ring
to do so.

In other words: If one *can* avoid symbolic expressions, then one *should*
avoid symbolic expressions.

Best regards,
Simon

[Nils Bruin]

On Monday, July 13, 2015 at 4:11:05 PM UTC+2, Simon King wrote:

In other words: If one *can* avoid symbolic expressions, then one *should*
avoid symbolic expressions.

 

That's just not going to fly for the casual/novice user:

sage: sqrt(2)
sqrt(2)
sage: QQbar(sqrt(2))
1.414213562373095?

Which of these two looks more exact to you?

[William Stein]

Hi,

Despite what other people are saying in this thread, I definitely 100%
consider the above a bug. Doing m == m1, should first coerce both to
SR, then compare there. Comparison there is supposed to currently
return true only if we can prove the two things are equal -- otherwise
false (that said, there is a proposal to raise an exception if
equality can't be determined, which I like).

I think at one point in time Robert Bradshaw implemented comparison in
SR using interval arithmetic and progressively higher precision; then
if that suggested equality (it can't ever prove it), then Sage would
fall back to other methods.

Anyways, definitely a very serious bug.

William

https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2015-07-13-084935-precision.sagews

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support...@googlegroups.com.
> To post to this group, send email to sage-s...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.

--
William (http://wstein.org)

[Nathann Cohen]

> Despite what other people are saying in this thread, I definitely 100%
> consider the above a bug.

Despite what you say about what other said, I also believe that it is
a bug and that others in this thread agree with you.

But what about *two* bugs?
1) SR says that two unequal things are equal, and it should not say so
unless it can *prove* it (and here it cannot)

2) Why should <an_integer> * sqrt(1/2) belong to SR? Why isn't it
turned into an algebraic number immediately? If it did, the problem,
would be solved too, for:

sage: QQbar(m) == m1
False

Nathann

[William Stein]

On Monday, July 13, 2015, Nathann Cohen <nathan...@gmail.com> wrote:

> Despite what other people are saying in this thread, I definitely 100%
> consider the above a bug.

Despite what you say about what other said, I also believe that it is
a bug and that others in this thread agree with you.

But what about *two* bugs?
1) SR says that two unequal things are equal, and it should not say so
unless it can *prove* it (and here it cannot)

+1

 

2) Why should <an_integer> * sqrt(1/2) belong to SR? Why isn't it
turned into an algebraic number immediately? If it did, the problem,

Nils answered 2 already and I agree with Nils. 

 

would be solved too, for:

    sage: QQbar(m) == m1
    False

Nathann

--
You received this message because you are subscribed to the Google Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my massive iPhone 6 plus.

[Nathann Cohen]

>> 2) Why should <an_integer> * sqrt(1/2) belong to SR? Why isn't it
>> turned into an algebraic number immediately? If it did, the problem,
>
> Nils answered 2 already and I agree with Nils.

I do not think that he did. The __repr__ function of algebraic numbers
is bad indeed, but if we can have this:

sage: QQbar(sqrt(2))
sqrt(2)

Then I believe that <an_integer>*sqrt(2) should be a member of QQbar,
and not rely on SymbolicRing.

I just created a thread about this __repr__ issue:
https://groups.google.com/forum/#!topic/sage-devel/dB-E7VjEFr4

Nathann

[Simon King]

Hi William,

On 2015-07-13, William Stein <wst...@gmail.com> wrote:
> Despite what other people are saying in this thread, I definitely 100%
> consider the above a bug.

My impression is that all participants of this thread agree that it is a bug.

> Doing m == m1, should first coerce both to
> SR, then compare there.

That's already the case.

> Comparison there is supposed to currently
> return true only if we can prove the two things are equal -- otherwise
> false

Correct, but in the current example SageMath behaves differently.

I just tried to come up with different examples exposing the buggy behaviour,
but failed. For example:

sage: R = RealField(1000)
sage: a = ZZ(floor(R(sqrt(2))*2^100))
sage: a.n() == (2^100*sqrt(2)).n()
True
sage: bool(a==2^100*sqrt(2))
False

So, why does SageMath give a correct answer in my example, but a wrong answer
in David's example?

Best regards,
Simon

[Volker Braun]

This is IMHO a bug in SR __nonzero__ only. Ginac/Pynac seems to handle the comparison just fine:

sage: RealField(300)(m) > RealField(300)(m1)

True

sage: RealField(300)(m) < RealField(300)(m1)

False

sage: cmp(SR(m), SR(m1))

-1

sage: cmp(RealField(100)(m), RealField(100)(m1))

-1

sage: bool(SR(m) > SR(m1))

True

sage: bool(SR(m) < SR(m1))

False

But this is wrong:

sage: (SR(m1) - SR(m)).__nonzero__()

False

[Volker Braun]

Which boils down to

sage: sage.symbolic.relation.test_relation_maxima(SR(m) == SR(m1))

True

Which comes from

$ sage --maxima

;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/sb-bsd-sockets.fas"

;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/sockets.fas"

;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/defsystem.fas"

;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/cmp.fas"

Maxima 5.35.1 http://maxima.sourceforge.net

using Lisp ECL 13.5.1

Distributed under the GNU Public License. See the file COPYING.

Dedicated to the memory of William Schelter.

The function bug_report() provides bug reporting information.

(%i1) is (equal(540579833922455191419978421211010409605356811833049025*sqrt(1/2), 

                382247666339265723780973363167714496025733124557617743));

(%o1)                                true

I suppose __nonzero__ should try to cast to QQbar and AA first before trying maxima.

[Anton Sherwood]

For fun I found the continued fraction expression
of the ratio of these two big integers:

1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 4, 1, 3, 12, 5, 1, 2, 1, 19,
3, 3, 3, 1, 1, 3, 2, 2, 3, 1, 5, 1, 4, 28, 2, 1, 3, 1, 2,
2, 1, 1, 1, 1, 10, 4, 1, 5, 6, 13, 1, 1, 2, 23, 1, 3, 16,
1, 29, 14, 4, 1, 3, 2.

It agrees with sqrt(2) for 70 steps.

--
*\\* Anton Sherwood *\\* www.bendwavy.org

[Ralf Stephan]

On Monday, July 13, 2015 at 7:24:36 PM UTC+2, Volker Braun wrote:

I suppose __nonzero__ should try to cast to QQbar and AA first before trying maxima.

Fixed and needs review:

http://trac.sagemath.org/ticket/18896

With this Sage would also pass one more test from Wester's paper. 

Regards,