BigFloat, BigInt comparison is intransitive

[StefanKarpinski]

julia> i1 = BigInt(10)^1000;

julia> i2 = BigInt("10000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000");

julia> i1 == i2
false

julia> i1 == BigFloat(10)^1000
true

julia> i2 == BigFloat(10)^1000
true

Discussion:

https://groups.google.com/forum/?fromgroups#!searchin/julia-dev/rational/julia-dev/2JcZdFKisis/Ag9rBJrrqQQJ

[quinnj]

Behavior probably changed with the hashing updates. Good to close?

In  [76]: i1 == i2

Out [76]: false

In  [77]:  i1 == BigFloat(10)^1000

Out [77]: false

In  [78]: i2 == BigFloat(10)^1000

Out [78]: false

[JeffBezanson]

That's really strange; I still get

julia> i1 == i2
false

julia> i1 == BigFloat(10)^1000
true

julia> i2 == BigFloat(10)^1000
true

[quinnj]

That's fishy. Is there a windows issue somewhere in here?

[quinnj]

What are the following for mac/linux?

In  [13]: a,b = promote(i2,BigFloat(10)^1000)

Out [13]: (1.000000000000000000000000000000000000000000000000000000000000000000000000000004e+1000 with 256 bits of precision,9.99999999999999999999999999999999999999999999999999999999999999999999999999968e+999 with 256 bits of precision)

In  [14]: (a.prec,b.prec)

Out [14]: (256,256)

In  [15]: a.sign,b.sign

Out [15]: (1,1)

In  [16]: a.exp,b.exp

Out [16]: (3322,3322)

In  [17]: a.d,b.d

Out [17]: (Ptr{Uint32} @0x0000000014c29ef8,Ptr{Uint32} @0x0000000014c29ec8)

[JeffBezanson]

Aha; I get

julia> a,b = promote(i2,BigFloat(10)^1000)
(1.000000000000000000000000000000000000000000000000000000000000000000000000000004e+1000 with 256 bits of precision,1.000000000000000000000000000000000000000000000000000000000000000000000000000004e+1000 with 256 bits of precision)

Looks like different rounding.

[quinnj]

Hmmm.......I'm seeing a test failure that I believe is related to this:
The test is test/mpfr.jl, lines 771-778

i1 = BigInt(10)^1000
i2 = BigInt("10000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000")
f = BigFloat(10)^1000
@test i1 != i2
@test i1 != f
@test i2 != f

@test f > i1

But I'm seeing:

julia> i1 = BigInt(10)^1000
10000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000

julia> f = BigFloat(10)^1000
9.99999999999999999999999999999999999999999999999999999999999999999999999999968e
+999 with 256 bits of precision

julia> f > i1
false

[andrioni]

That's pretty weird, since not even rounding down BigFloat(10)^1000 I can reproduce your issue on OS X, since the answer you get is even smaller:

julia> f = BigFloat("9.99999999999999999999999999999999999999999999999999999999999999999999999999968e+999")
9.99999999999999999999999999999999999999999999999999999999999999999999999999968e+999 with 256 bits of precision

julia> g = with_rounding(BigFloat, RoundDown) do
         BigFloat(10)^1000
       end
9.999999999999999999999999999999999999999999999999999999999999999999999999999953e+999 with 256 bits of precision

julia> g > f
true

[Keno]

Could this be an mpfr problem. I notice the mpfr structures are significantly smaller on windows due to the whole ILP64 vs LLP64 thing.

[tkelman]

Found a simple fix for this Win64 test failure, PR incoming. BigFloat^Int goes to MPFR on every platform other than Win64, because Win64 is the only place that Julia Int is bigger than Clong. On Win64 it's going to power_by_squaring resulting in a differently-rounded result.