digitalmars.D.announce - Proposal for a standard Decimal type in alpha
- Jack Stouffer (18/18) Dec 21 2017 A couple of months ago, Andrei noted that a donor asked for a
- Andre Pany (9/27) Dec 21 2017 That are fantastic news. Thanks for working on this topic.
- Jack Stouffer (9/14) Dec 21 2017 Yes, the Hook template parameter currently controls how many
- Walter Bright (4/6) Dec 21 2017 Thanks for doing this.
- Nathan S. (9/19) Dec 22 2017 I think it would be clearer if the precision, the rounding mode,
- Andre Pany (8/15) Dec 22 2017 I agree. I worked with languages which have decimal type built
- Jack Stouffer (10/11) Jan 05 2018 Updated version out:
- H. S. Teoh (5/17) Jan 05 2018 Very nice to see this taking shape. What's the link to the code again?
- Jack Stouffer (2/4) Jan 05 2018 https://github.com/JackStouffer/stdxdecimal
- H. S. Teoh (5/9) Jan 05 2018 Thanks! Will take a look sometime. Might throw in a PR or two if I can.
- Jack Stouffer (10/20) Jan 05 2018 Well hold off on that for a day because I just realized I have to
- Jack Stouffer (5/6) Jan 12 2018 While I believe my library has certain API advantages, I'm really
- rumbu (17/23) Jan 13 2018 This is not good idea. Since your project is based on a BigInt
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (6/12) Mar 14 2018 I was daydreaming today about using D to replace a certain Python
- Seb (3/16) Mar 14 2018 https://forum.dlang.org/thread/mutegviphsjwqzqfouhs@forum.dlang.org?page...
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (5/6) Mar 14 2018 While certainly impressive and feature-complete, rumbu's isn't a
- rumbu (5/11) Mar 14 2018 For 20 decimal digits, you can use decimal128 (having a 34
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (4/7) Mar 14 2018 I would also sometimes like around 1000 decimal digits. It's fun
- rumbu (15/23) Mar 14 2018 To store 1000 decimal digits you will need 3322 bits. My decimal
- Gary Willoughby (4/9) Mar 14 2018 Why not polish the one up in the review queue?:
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
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
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
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
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 typesI 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
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
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 2018
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: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??...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 2018
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 2018
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: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.Very nice to see this taking shape. What's the link to the code again?https://github.com/JackStouffer/stdxdecimal
Jan 05 2018
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: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.On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote:Thanks! Will take a look sometime. Might throw in a PR or two if I can. TVery nice to see this taking shape. What's the link to the code again?https://github.com/JackStouffer/stdxdecimal
Jan 05 2018
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 2018
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: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....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 13 2018
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: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....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.
Mar 14 2018
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:https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: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....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.
Mar 14 2018
On Wednesday, 14 March 2018 at 14:29:48 UTC, Seb wrote:https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1While 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 2018
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:For 20 decimal digits, you can use decimal128 (having a 34 decimal digits precision) and set the context precision to 20.https://forum.dlang.org/thread/mutegviphsjwqzqfouhs forum.dlang.org?page=1While 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 2018
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.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 2018
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: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.For 20 decimal digits, you can use decimal128 (having a 34 decimal digits precision) and set the context precision to 20.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 2018
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 2018