decimal (optional?) support

[inv2004]

• choose decimal lib (rust_decimal ?)
• compare performance
• implement

[SeanKim]

Hello maintainer, I've been doing some research on this topic recently, so I want to tell you my opinion on this part.

I think using "String" as-is is the best choice for this crate,
because the reason why we need some monetary data type is for arithmetic operations. inside this crate, However, we do not perform any arithmetic operations.
this crate is responsible for communicate with coinbase, not for arithmetic operation. So I think it's a good idea to leave it up to the user to decide which monetary data type (like rust-decimal) to use.

If rust-decimal is the only best option for monetary data type, it will be good idea to use it as base data type for this crate. but it is inherently slower than some other options. below is the simple benchmark result of arithmetic operation. d128, decimal, f64 correspond to IBM's decnumber(IEEE754-2008 DPD implementation), rust-decimal, f64 respectively.

as you see rust-decimal is much more slower than f64.

I know f64 is not a good option for financial calculation. (some say it's fine in most realistic value range if you round the value after every operation. I'm not sure whether this proposition is true or not.) However, there are the way to achieve performance comparable to the f64. you can rescale the value to make it into integer and doing arithmetic operation with integer value. For example, BTC's quote_increment is 0.01 at coinbase, so that we can convert BTC price as integer by multiplying it with 100. This method has a downside that user should take in mind that the value is rescaled, but it will be much more faster than rust-decimal.

In conclusion, I think user should choose which data type to use. if they want to simple solution to solve precision error, use rust-decimal(or arbitrary precision type), and if they care about speed, use integer-rescale(or f64 with rounding?). It will be better for this crate to not limit the user's choice.

thanks for reading! I'll look forward to hearing your opinion.

[inv2004]

@SeanKim Awesome exploration. Thank you.

I really did not expect decimal is so slow, I know there are a lot of different implementations, but I expect that one of them is just to fix precision (0.01 for the BTC) and I expected that it has +- the same performance like 100* solution.