Live data from Hacker News

Fixed – Fixed-place decimal math library for Go

github.com

21–30 of 73 posts

Re: Fixed – Fixed-place decimal math library for Go

#21

I'm a bit surprised to see floating point being used for multiplication, division etc. I would have expected to see this implemented with integers as well (with each operation changing the position of the point).

Floating point multiplication can be faster than integer multiplication on modern CPUs. Check out this thread for lots of info!

https://stackoverflow.com/q/2550281/164234

Re: Fixed – Fixed-place decimal math library for Go

#22
post #8

Earlier quoted context omitted.

I work in Finance, I don't use float, and I suggest you never do either.

As a concrete example, someone was running a massive online FFI for predicting the value of derivatives, and they were doing it in the real domain and using doubles on GPUs for monetary values. Where they doing it 'wrong' then? I don't know much about finance myself.

I think the problem here is that "financial computing" is too broad a term to apply a rule like that blindly. If you're making products like point-of-sale systems, ecommerce applications or account management, then it's basically malpractice to use floating point. The performance edge you get from them is so slight in the overall performance of the system and the damage bugs cause can be catastrophic. And it's very easy to get them wrong. It's pretty trivial in most languages to swap in decimal and/or rational types, so NOT doing so is just irresponsible.

However, if you're doing things like high-frequency trading systems or machine learning stuff with massive amounts of data, then performance really does matter, and using floating point is entirely reasonable. If you're making systems like that, you're hopefully aware of the limitations of floating point and know how to use them safely.

Re: Fixed – Fixed-place decimal math library for Go

#23
post #18

Earlier quoted context omitted.

With a bank balance on a computer.

Can computer bank balances store fractional cents right now? At least before, this was not possible.

The question is can computers do arbitrary precision arithmetic. Technically you'd need infinite memory, but if you use fractions to represent amounts, as is correct, then practically speaking, yes you can. One accounting system that uses fractions is ledger[0].

[0] https://www.ledger-cli.org/

Re: Fixed – Fixed-place decimal math library for Go

#24

You'll never get good performance without using assembly. GMP probably walks all over this. Even my own bignum library probably walks all over it for addition and subtraction.

Would you like to show us a benchmark of your bignum library?

Re: Fixed – Fixed-place decimal math library for Go

#27

You'll never get good performance without using assembly. GMP probably walks all over this. Even my own bignum library probably walks all over it for addition and subtraction.

Where can we find your bignum library?

You can find it on github along with a hundred others. But you should use GMP. It's better than anything you or I could do alone.

Re: Fixed – Fixed-place decimal math library for Go

#28
post #18

Earlier quoted context omitted.

Can computer bank balances store fractional cents right now? At least before, this was not possible.

The question is can computers do arbitrary precision arithmetic. Technically you'd need infinite memory, but if you use fractions to represent amounts, as is correct, then practically speaking, yes you can. One accounting system that uses fractions is ledger[0]. [0] https://www.ledger-cli.org/

Six or seven digits of precision (like all floating point) is good enough, and far better than exactly 2 digits of decimal. Millions of times better.

Fractions do little for interest rates, which are transcendental functions and sometimes even irrational.

Re: Fixed – Fixed-place decimal math library for Go

#30

It's always struck me as strange than finance folk don't want correct math. They want math that matches the coins in their pocket. If I am owed 2.575% on $3425956.57 for 245 months, why not get the correct sum instead of some rounded monthly sum added up? Its just strange.

They have it in COBOL,which uses binary coded decimals to represent the number (1 decimal per nibble) so numbers like 0.3 can be represented without loss of accuracy. It was abandoned in favour of IEEE754.
Post reply on HN