"Questionable Pull": Fixed BigInt bug & added BigFloat

[choffstein]

I fixed a bug in the wrapper library and added some code to enable a BigFloat.

Unfortunately, my BigFloat tests don't pass because I haven't quite figured out the type-conversions. If someone knowledgable can take a look at jl/bigfloat.jl at the conversions, they should be fix it pretty quickly to get the tests passing.

[choffstein]

I probably should have split this into two pull requests -- the first to fix BigInt, and the second to add BigFloat. If you only want to do the former, you can change gmp_wrapper.c _jl_mpz_printf to the following:

extern char*  _jl_mpz_printf(mpz_t* rop) {
    char* pp;
    gmp_asprintf(&pp, "%Zd", *rop);
    return pp;
}

[aviks]

I've managed to get the converts changed enough to give us correct arithmetic

julia> a=BigFloat("12.34567890121")
12.34567890121

julia> a+0.00000000001
12.3456789012199999999

However, some more work is needed on the comparisons. In general, == will not work for comparing floats on the tests, we'll need to use abs(..) < eps. But even beyond that, I am having problems with the comparisons, they seem inconsistent. I'll take a further look tomorrow.

Another minor comment: do we want to implicitly convert Unsigned values? or just singed ones?

[aviks]

@choffstein : The following is the diff that I have to your bigfloat at the moment.

bash-3.2$ git diff jl/bigfloat.jl 
diff --git a/jl/bigfloat.jl b/jl/bigfloat.jl
index 2f6cb57..bbbc5bf 100644
--- a/jl/bigfloat.jl
+++ b/jl/bigfloat.jl
@@ -13,7 +13,7 @@ type BigFloat <: Float
                b
        end

-       function BigFloat(x::Float) 
+       function BigFloat(x::Float64) 
                z = _jl_BigFloat_init()
                ccall(dlsym(_jl_libgmp_wrapper, :_jl_mpf_set_d), Void, (Ptr{Void}, Float), z, x)
                b = new(z)
@@ -52,18 +52,24 @@ type BigFloat <: Float
        end
 end

-convert(::Type{BigFloat}, x::Int8)   = BigFloat(x)
-convert(::Type{BigFloat}, x::Int16)  = BigFloat(x)
-convert(::Type{BigFloat}, x::Int32)  = BigFloat(x)
-convert(::Type{BigFloat}, x::Int64)  = BigFloat(x)
-convert(::Type{BigFloat}, x::Uint8)  = BigFloat(x)
-convert(::Type{BigFloat}, x::Uint16) = BigFloat(x)
-convert(::Type{BigFloat}, x::Uint32) = BigFloat(x)
-convert(::Type{BigFloat}, x::Uint64) = BigFloat(x)
-
-convert(::Type{BigFloat}, x::Float) = BigFloat(x)
-convert(::Type{BigFloat}, x::Float32) = BigFloat(x)
+convert(::Type{BigFloat}, x::Int8)   = BigFloat(int(x))
+convert(::Type{BigFloat}, x::Int16)  = BigFloat(int(x))
+convert(::Type{BigFloat}, x::Int)  = BigFloat(x)
+macro define_bigint_convert ()
+       if WORD_SIZE == 64
+               :(convert(::Type{BigFloat}, x::Int32) = BigInt(int(x)))
+               :(convert(::Type{BigFloat}, x::Uint32) = BigFloat(int(x)))
+
+       else
+               :(convert(::Type{BigFloat}, x::Int64) = BigInt(string(x)))
+               :(convert(::Type{BigFloat}, x::Uint64) = BigFloat(int(x)))
+       end
+end
+@define_bigint_convert
+convert(::Type{BigFloat}, x::Uint8)  = BigFloat(int(x))
+convert(::Type{BigFloat}, x::Uint16) = BigFloat(int(x))
 convert(::Type{BigFloat}, x::Float64) = BigFloat(x)
+convert(::Type{BigFloat}, x::Float32) = BigFloat(float64(x))

 promote_rule(::Type{BigFloat}, ::Type{Float32}) = BigFloat
 promote_rule(::Type{BigFloat}, ::Type{Float64}) = BigFloat

[nolta]

Hmm, i don't think type-conversion is the problem. The tests fail even if the float literals are replaced with BigFloats.

Are you sure the tests shouldn't fail? I came across this in the manual:

The mantissa in stored in binary, as might be imagined from the fact precisions are expressed in bits. One consequence of this is that decimal fractions like 0.1 cannot be represented exactly. The same is true of plain IEEE double floats. This makes both highly unsuitable for calculations involving money or other values that should be exact decimal fractions. (Suitably scaled integers, or perhaps rationals, are better choices.)

http://gmplib.org/manual/Floating_002dpoint-Functions.html

[aviks]

Yes, of course, tests like (a + .00000001 == b) will never work.

However, I would expected, for example, (a + .00000001 -b < .00000001 ) to work. Visually, given the rounding errors, that should work.

Even more simply, a > 0.0 does not work, but a > BigFloat(0) does .

Note that you'll need to apply my diff above, otherwise the addition itself does not work correctly.

[choffstein]

Yeah, momentary lapse. I was thinking that they were infinite precision structures -- but they aren't. Thanks for helping to clean it up.

[aviks]

There is an assert_approx_eq macro in runtest.jl now that seems to compare to an difference of 1.0e-6