Add a BigDecimal type

[sfackler]

libextra already has BigInt, BigUint and BigRational but not an arbitrary precision decimal type similar to Java's BigDecimal or SQL's NUMERIC type.

[emberian]

This should be pretty easy. The hard part is getting it performant. Not particularly important.

[pongad]

Sorry for a probably stupid question, isn't BigRational and BigDecimal functionally the same thing? They all represent rational numbers right?

[sfackler]

BigDecimal types traditionally allow you to specify their precision and the rounding mode used for operations.

[pongad]

I thought I was a decent computer scientist, then I met this community xD

[derekchiang]

May I claim this issue?

I will need to give this more thoughts, but atm I think this should work:

struct BigDecimal {
    value: BigInt,
    scale: BigInt,
    // ... some other fields if needed
}

And the actual value will just be value * 10^-scale, i.e. value times ten to the power of the negation of scale. This is the way Java does it.

Any thoughts?

[emberian]

Go for it! If that's what Java does and there's no alternative numerics
library for it that does far better, it sounds like a fine strategy.

On Fri, Jan 10, 2014 at 10:30 AM, Derek Chiang (Enchi Jiang) <
[email protected]> wrote:

May I claim this issue?

I will need to give this more thoughts, but atm I think this should work:

struct BigDecimal {
value: BigInt,
scale: BigInt,
// ... some other fields if needed}

And the actual value will just be value^-scale, i.e. value to the power
of the negation of scale. This is the way Java does ithttp://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html
.

Any thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8937#issuecomment-32036398
.

[huonw]

And the actual value will just be value^-scale, i.e. value to the power of the negation of scale

I think you mean value * 10^-scale, i.e. value = 12345, scale = 3 represents 12345 * 10^-3 = 12345/1000 = 12.345.

[derekchiang]

@huonw indeed. Fixed.

[nicolasboulay]

Maybe a BigDouble, could be done with

struct BigDouble {
value: array double ,
// ... some other fields if needed
}

Sometime arbitrary precision library are done with integer, wich could be much slower than using 2 or 3 double, with the correct operation.

[mrshu]

Off topic question: is there a good reason why is this labeled with both E-easy and E-hard? It seems to me that the former is the opposite of the latter.

[emberian]

@mrshu writing a BigDecimal is easy. Writing a good BigDecimal is hard.

[aochagavia]

Since I see there has been no progress here, I am going to implement this.

[lee-b]

Is there any particular problem with just wrapping libgmp for this sort of stuff? Seems like C++ libs wrap the C code easily enough.

[sfackler]

I would personally be in favor of dumping our current BigInt stuff and wrapping GMP (BigInteger is ~100x slower than GMP's version in many cases!), but there may be some trickiness involved since GMP is LGPL. I don't think that's a hard blocker though.

[aochagavia]

I think it is a good idea... Porting the code from Java is a non-trivial task and will probably perform worse than libgmp.

[vks]

GMP has many hardware-specific optimizations. It does not seem feasible to me to reimplement them in Rust.

[vks]

I think this should be implemented on top of MPFR [1]. Similarly, BigInt should be implemented on top of GMP [2].
Currently BigInt lacks in performance and features.

About LGPL: I think we should be fine if we dynamically link against it (like it is done in rust-gmp [3]).

[1] http://www.mpfr.org/
[2] https://gmplib.org/
[3] https://github.com/thestinger/rust-gmp

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#334

[rust-highfive]

This issue has been moved to the RFCs repo: rust-num/num#8