January 05
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.
January 12
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.
January 13
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.
Next ›   Last »
1 2