Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a BigDecimal type #8937

Closed
sfackler opened this issue Sep 2, 2013 · 19 comments
Closed

Add a BigDecimal type #8937

sfackler opened this issue Sep 2, 2013 · 19 comments
Labels

Comments

@sfackler
Copy link
Member

@sfackler sfackler commented Sep 2, 2013

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
Copy link
Member

@emberian emberian commented Jan 6, 2014

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

@pongad
Copy link
Contributor

@pongad pongad commented Jan 9, 2014

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

@sfackler
Copy link
Member Author

@sfackler sfackler commented Jan 9, 2014

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

@pongad
Copy link
Contributor

@pongad pongad commented Jan 9, 2014

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

@derekchiang
Copy link
Contributor

@derekchiang derekchiang commented Jan 10, 2014

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
Copy link
Member

@emberian emberian commented Jan 10, 2014

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) <
notifications@github.com> 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
Copy link
Member

@huonw huonw commented Jan 10, 2014

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
Copy link
Contributor

@derekchiang derekchiang commented Jan 10, 2014

@huonw indeed. Fixed.

@nicolasboulay
Copy link

@nicolasboulay nicolasboulay commented Jan 23, 2014

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
Copy link
Contributor

@mrshu mrshu commented Feb 9, 2014

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
Copy link
Member

@emberian emberian commented Feb 9, 2014

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

@aochagavia
Copy link
Contributor

@aochagavia aochagavia commented Jun 5, 2014

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

@lee-b
Copy link

@lee-b lee-b commented Jul 7, 2014

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
Copy link
Member Author

@sfackler sfackler commented Jul 7, 2014

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
Copy link
Contributor

@aochagavia aochagavia commented Jul 8, 2014

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
Copy link
Contributor

@vks vks commented Aug 17, 2014

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

@vks
Copy link
Contributor

@vks vks commented Sep 4, 2014

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
Copy link
Collaborator

@rust-highfive rust-highfive commented Sep 28, 2014

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

@rust-highfive
Copy link
Collaborator

@rust-highfive rust-highfive commented Sep 28, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.