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.

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.

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.

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.

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

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?

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

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

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?

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.