www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Proposal for a standard Decimal type in alpha

reply Jack Stouffer <jack jackstouffer.com> writes:
A couple of months ago, Andrei noted that a donor asked for a 
precise decimal type for D specifically: 
https://forum.dlang.org/post/osnema$d5s$1 digitalmars.com. I've 
also heard this asked for many times, so I decided to start work 
on a library for eventual proposal to Phobos.

I just finished getting the type into an alpha version, and I 
wanted to solicit people's opinions on the API and if I'm heading 
in the right direction with this.

The dub page: https://code.dlang.org/packages/stdxdecimal

The docs: https://jackstouffer.github.io/stdxdecimal/

What you can do so far:

* Control behavior with a Hook type a-la 
std.experimental.checkedint
* Addition, subtraction, multiplication, division
* Construction from a strings and built-in number types

For the full list of planned features, see: 
https://github.com/JackStouffer/stdxdecimal

Please let me know what you think!
Dec 21 2017
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
 A couple of months ago, Andrei noted that a donor asked for a 
 precise decimal type for D specifically: 
 https://forum.dlang.org/post/osnema$d5s$1 digitalmars.com. I've 
 also heard this asked for many times, so I decided to start 
 work on a library for eventual proposal to Phobos.

 I just finished getting the type into an alpha version, and I 
 wanted to solicit people's opinions on the API and if I'm 
 heading in the right direction with this.

 The dub page: https://code.dlang.org/packages/stdxdecimal

 The docs: https://jackstouffer.github.io/stdxdecimal/

 What you can do so far:

 * Control behavior with a Hook type a-la 
 std.experimental.checkedint
 * Addition, subtraction, multiplication, division
 * Construction from a strings and built-in number types

 For the full list of planned features, see: 
 https://github.com/JackStouffer/stdxdecimal

 Please let me know what you think!
That are fantastic news. Thanks for working on this topic. Is it possible to define a decimal type with a defined scale and precision? From the examples and the documentation I am not sure whether it is possible. Kind regards Andre
Dec 21 2017
parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 21 December 2017 at 23:08:22 UTC, Andre Pany wrote:
 That are fantastic news. Thanks for working on this topic.
 Is it possible to define a decimal type with a defined scale 
 and precision?
 From the examples and the documentation I am not sure whether 
 it is possible.
Yes, the Hook template parameter currently controls how many significant digits your decimal can have and will eventually be able to control the min and max allowed exponents as well. By default, it's set at 9 digits, but you can have as many as int.max - 1 since it auto uses BigInt under the hood. Once your decimal has more than the allowed number of digits, it's rounded according to the Hook prescribed rounding method, which is half up by default.
Dec 21 2017
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2017 5:59 AM, Jack Stouffer wrote:
 I just finished getting the type into an alpha version, and I wanted to
solicit 
 people's opinions on the API and if I'm heading in the right direction with
this.
Thanks for doing this. Your proposal would be enhanced a lot if it included a comparison with successful decimal packages in other languages, and why your solution is better!
Dec 21 2017
prev sibling next sibling parent reply Nathan S. <no.public.email example.com> writes:
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
 I just finished getting the type into an alpha version, and I 
 wanted to solicit people's opinions on the API and if I'm 
 heading in the right direction with this.

 The dub page: https://code.dlang.org/packages/stdxdecimal

 The docs: https://jackstouffer.github.io/stdxdecimal/

 What you can do so far:

 * Control behavior with a Hook type a-la 
 std.experimental.checkedint
 * Addition, subtraction, multiplication, division
 * Construction from a strings and built-in number types
I think it would be clearer if the precision, the rounding mode, and the error behavior were three separate parameters instead of a single Hook. Predefined settings named "Abort", "Throw", and "NoOp" would then be self-explanatory, and it wouldn't be necessary to entirely rewrite them if you wanted precision of 10 or 20 decimal digits instead of 9 or wanted to use a different rounding mode.
Dec 22 2017
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 22 December 2017 at 08:32:03 UTC, Nathan S. wrote:
 I think it would be clearer if the precision, the rounding 
 mode, and the error behavior were three separate parameters 
 instead of a single Hook. Predefined settings named "Abort", 
 "Throw", and "NoOp" would then be self-explanatory, and it 
 wouldn't be necessary to entirely rewrite them if you wanted 
 precision of 10 or 20 decimal digits instead of 9 or wanted to 
 use a different rounding mode.
I agree. I worked with languages which have decimal type built into the language (DATA price TYPE p LENGTH 16 DECIMALS 2) and having the possibility to set precision and scale directly without have to think about rounding options would be great. Kind regards Andre
Dec 22 2017
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
 ...
Updated version out: * Added unary +,-,++,-- * Added casting to bool and floating point types * Added static ctors for infinite and nan for floating point type compatibility * Added abs, isNaN, isInfinite * Added support to opBinary for mixing different precision levels on each side of the operation
Jan 05
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 05, 2018 at 02:30:21PM +0000, Jack Stouffer via
Digitalmars-d-announce wrote:
 On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote:
 ...
Updated version out: * Added unary +,-,++,-- * Added casting to bool and floating point types * Added static ctors for infinite and nan for floating point type compatibility * Added abs, isNaN, isInfinite * Added support to opBinary for mixing different precision levels on each side of the operation
Very nice to see this taking shape. What's the link to the code again? T -- Why do conspiracy theories always come from the same people??
Jan 05
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote:
 Very nice to see this taking shape.  What's the link to the 
 code again?
https://github.com/JackStouffer/stdxdecimal
Jan 05
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 05, 2018 at 03:38:45PM +0000, Jack Stouffer via
Digitalmars-d-announce wrote:
 On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote:
 Very nice to see this taking shape.  What's the link to the code again?
https://github.com/JackStouffer/stdxdecimal
Thanks! Will take a look sometime. Might throw in a PR or two if I can. T -- Why did the mathematician reinvent the square wheel? Because he wanted to drive smoothly over an inverted catenary road.
Jan 05
parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 5 January 2018 at 15:44:57 UTC, H. S. Teoh wrote:
 On Fri, Jan 05, 2018 at 03:38:45PM +0000, Jack Stouffer via 
 Digitalmars-d-announce wrote:
 On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote:
 Very nice to see this taking shape.  What's the link to the 
 code again?
https://github.com/JackStouffer/stdxdecimal
Thanks! Will take a look sometime. Might throw in a PR or two if I can. T
Well hold off on that for a day because I just realized I have to redesign the internals of the whole thing due to a bug I found. Long story short, I'd been using a myriad of different types (depending on your chosen precision) to represent the coefficient in order to avoid the slowness of BigInt. But I realized due to a bug that this isn't really a workable solution. I'm going to change the code to always use a BigInt, and just work on making BigInt faster where I can. This will make the Decimal code about half as complex thankfully.
Jan 05
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
 ...
While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.
Jan 12
next sibling parent rumbu <rumbu rumbu.ro> writes:
On Friday, 12 January 2018 at 15:44:01 UTC, Jack Stouffer wrote:
 On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
 wrote:
 ...
While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.
This is not good idea. Since your project is based on a BigInt storage, it will be the perfect candidate for a BigDecimal data type. I explored also BigInt as storage for the decimal128 data type, but finally I ended writing my own fixed precision unsigned type in a recursive manner, mainly because of the BigInt dependency of the garbage collector. Internally, my decimal library is performing calculations on maximum 256 bits, so BigInt was more than I needed. Also, your project is built mainly on IBM decimal concepts and mine on Intel's ones. During my exploration, I found that there is a cold war between IBM and Intel regarding the decimal standard (the main bone of contention being how to store digits). There are benchmarks on both parts (which obviously favor the benchmarker), but you cannot trust them. It will be nice to have both concepts in D and benchmark them independently.
Jan 13
prev sibling parent reply Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
On Friday, 12 January 2018 at 15:44:01 UTC, Jack Stouffer wrote:
 On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
 wrote:
 ...
While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.
I was daydreaming today about using D to replace a certain Python computation module at work, but to do this, we really require a bigfloat/bigdecimal type. I think I might want to help completing this work, either your's or rumbu's. What's the code to look at? I found yours, but I couldn't find rumbu's.
Mar 14
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 14 March 2018 at 14:23:44 UTC, Jordi Gutiérrez 
Hermoso wrote:
 On Friday, 12 January 2018 at 15:44:01 UTC, Jack Stouffer wrote:
 On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
 wrote:
 ...
While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.
I was daydreaming today about using D to replace a certain Python computation module at work, but to do this, we really require a bigfloat/bigdecimal type. I think I might want to help completing this work, either your's or rumbu's. What's the code to look at? I found yours, but I couldn't find rumbu's.
https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1
Mar 14
parent reply Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
On Wednesday, 14 March 2018 at 14:29:48 UTC, Seb wrote:
 https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1
While certainly impressive and feature-complete, rumbu's isn't a bigdecimal library. I need arbitrary precision (in this case, exactly 20 decimal digits), not only IEEE 754 decimals. Jack, I think that's what you're doing instead?
Mar 14
parent reply rumbu <rumbu rumbu.ro> writes:
On Wednesday, 14 March 2018 at 14:41:21 UTC, Jordi Gutiérrez 
Hermoso wrote:
 On Wednesday, 14 March 2018 at 14:29:48 UTC, Seb wrote:
 https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1
While certainly impressive and feature-complete, rumbu's isn't a bigdecimal library. I need arbitrary precision (in this case, exactly 20 decimal digits), not only IEEE 754 decimals. Jack, I think that's what you're doing instead?
For 20 decimal digits, you can use decimal128 (having a 34 decimal digits precision) and set the context precision to 20. http://rumbu13.github.io/decimal/doc/decimal.html#.DecimalControl.precision
Mar 14
parent reply Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
On Wednesday, 14 March 2018 at 14:57:12 UTC, rumbu wrote:
 For 20 decimal digits, you can use decimal128 (having a 34 
 decimal digits precision) and set the context precision to 20.

 http://rumbu13.github.io/decimal/doc/decimal.html#.DecimalControl.precision
I would also sometimes like around 1000 decimal digits. It's fun to compute digits of pi, especially today (or zeta(3) or whatever). Can yours do that?
Mar 14
parent rumbu <rumbu rumbu.ro> writes:
On Wednesday, 14 March 2018 at 15:18:18 UTC, Jordi Gutiérrez 
Hermoso wrote:
 On Wednesday, 14 March 2018 at 14:57:12 UTC, rumbu wrote:
 For 20 decimal digits, you can use decimal128 (having a 34 
 decimal digits precision) and set the context precision to 20.

 http://rumbu13.github.io/decimal/doc/decimal.html#.DecimalControl.precision
I would also sometimes like around 1000 decimal digits. It's fun to compute digits of pi, especially today (or zeta(3) or whatever). Can yours do that?
To store 1000 decimal digits you will need 3322 bits. My decimal implementation is performance/precision oriented not arbitrary precision oriented. What you'll need is a BigFloat or BigDecimal type. At the origin, my decimal implementation used an unlimited bit width, but trying to compile it with an width greater than 1024 bits resulted in out of memory or in compilation times measured in tens of minutes, therefore I limited the use to 128 bit, as requested in the IEEE 754-2008 standard. For your needs Jack's solution (https://github.com/JackStouffer/stdxdecimal) is better since it's using BigInt as storage, therefore you'll have any arbitrary precision you desire.
Mar 14
prev sibling parent Gary Willoughby <dev nomad.so> writes:
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:
 A couple of months ago, Andrei noted that a donor asked for a 
 precise decimal type for D specifically: 
 https://forum.dlang.org/post/osnema$d5s$1 digitalmars.com. I've 
 also heard this asked for many times, so I decided to start 
 work on a library for eventual proposal to Phobos.
Why not polish the one up in the review queue?: https://wiki.dlang.org/Review_Queue
Mar 14