Use libmpdec under the hood instead of current approach?

[alexandergunnarson]

Amazing library!

Curious if you've considered keeping the same API but using libmpdec under the hood instead of the current approach (BigInt + Bool + Int), for performance reasons.

[barucden]

I've only been maintaining this package for the past year, so I don't know if libmpdec has ever been considered.

We still need to implement some basic operations (e.g., exp or log) here, and they are tricky to get right — or at least I haven't succeeded to come up with definitions that would pass all tests. So, from that point of view, it sounds reasonable to use a well-tested library in the background that already provides correct implementation.

On the other hand, my understanding is that being implemented in Julia is one of the (secondary) features of Decimals.jl. Also, I should note that libmpdec and Decimals.jl differ in some aspects; for example, we don't operate with special values (NaN or infinities).

You mentioned performance concerns. Are these concerns specific, or general? I've mostly focused on implementing missing operations and payed only little attention to speed, so I imagine our performance is not optimal, but I believe we should be able to match (or at least approach) the speed of any C library.

[stevengj]

I believe we should be able to match (or at least approach) the speed of any C library.

While this should be possible, it may not be worthwhile. It's a lot of work to get the performance of an arbitrary-precision package comparable to a library that has seen heavy optimization effort. Just using an existing library like libmpdec or IBM decNumber would give a lot of features with a lot less code and effort.

(And supporting NaN and Inf (#116) is useful for any floating-point library, in my opinion.)