Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixed – Fixed-place decimal math library for Go

github.com

Post reply on HN
Print view View original

51–60 of 73 posts

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

#51

Post by dragonwriter »

chrisseaton wrote: post #12
segmondy wrote: 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.

Predicting is inherently approximate; accounting needs to be exact. They may use similar units, but they are different kinds of problems.

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

#53

Post by twic »

segmondy wrote: post #8
chrisseaton wrote: post #4

Earlier quoted context omitted.

Despite what everyone says, I've spoken to several different people at several different highly-regarded banks who say that they do, in fact, use floating point for money amounts in some of their systems. What experience do people who work in banks have?

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

I work in finance, and i use floats (well, doubles) all the time!

I never use floats for any quantities which i need to exactly add up to a known total, of course.

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

#54

Post by roywiggins »

JoeAltmaier wrote: post #28
black-tea wrote: post #23

Earlier quoted context omitted.

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.

It isn't enough. Suppose you have something in dollars and cents (in a float), and you want a count of pennies.

2.22 * 100.0 == 222.00000000000003, not 218.0. This is a) wrong and b) not an integer.

Either you are aware of this and manually round the result to an integer, or you use fixed-point math.

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

#55

Post by nitwit005 »

JoeAltmaier wrote: post #11

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.

Because cash is obviously still a thing?

Be glad we at least have a decimal based coinage system these days. We'd all have such fun dealing with fractions.

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

#56

Post by strainer »

chank wrote: post #39

I work in the accounting space. In the current systems we develop today this would need to be able to handle trillions(up to 14 places) at least and most likely quadrillions(up to 17 spaces) These amounts happen already due to certain countries with high inflation levels.

The ubiquitous float Double has 15 places of accuracy that is secure for summing integers up to that size.

I think the core frustration is how values less than one are subject to about 1 million-billionth part of noise, which could be tolerated except that factors like inflation are recorded as fixed decimals.

For example, if monthly inflation is standardized as 5 significant digits, then for 0.0012345 - the rounding to 5 sd actually introduced about one hundred-thousandth part of noise to whatever the real value was, but the number is then considered precise. Subsequent encoding of 0.0012345 to a float Double is ten billion times less imprecise than the writing of 0.00123447... to 5 sd was, but it is an unwanted inconsistency that is difficult to securely keep out of the fixed point results, even though they are kept to much lower precision.

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

#57

Post by justincormack »

jandrese wrote: post #43
JoeAltmaier wrote: post #33

Earlier quoted context omitted.

I think that was a holdover of EBCDIC, an old IBM standard. In fact early IBM machines did BCD in their ALU.

BCD mode was a popular in a lot of early chips. It's an esoteric feature today, but on 16 bit machines you would blow out the ALU way too easily and get into messy two word math.

x86 still has BCD support, in 32 bit mode http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaa...

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

#58

Post by sdinsn »

dmoy wrote: post #18
JoeAltmaier wrote: post #16

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.

They must be able to, since brokers often use fractions of cents for penny stocks.

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

#59

Post by robaho »

As the author of Fixed, I'd like to make a few comments:

1. If you are above 100 billion, you are probably dropping the the 'fractions' and dealing with whole numbers. Most databases don't have their columns configured as Decimal(64,64) for 128 digits. It's not practical. So I would store the amounts above 100 billion in another value - the billions unit. And if you are 100s of billion, I am pretty certain you're not concerned with .0000001 dollars. Most 'terminals/receipts' couldn't show/print a number that high without truncating or the UI/representation would be all messed up.

2. I don't believe the crypto-currency space needs more than 7 places on an exchange. The CME only supports 8 decimal places in their protocol. Most of these issues are handled by reinterpreting the scale & quantity. "The satoshi is currently the smallest unit of the bitcoin currency recorded on the block chain. It is a one hundred millionth of a single bitcoin (0.00000001 BTC)." and since there can only be 21 million BTC, it easily fits - although I would probably change the code to use 8 decimal places for ease of use.

3. I might add more rounding modes. They are trivial, but there are some pretty exotic ones - so implementing them all internally, rather than externally can be problematic.

4. For the gamers that say they need float32 - there are more digits of precision in Fixed that float32 - just change the number of places in the code... if you need less significand and more decimals.

5. I've added integer Mul. It is about 2x faster than using floating point. If you avoid limiting overflow, which it doesn't, it is closer to 10x.

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

#60

Post by andreygrehov »

robaho wrote: post #59

As the author of Fixed, I'd like to make a few comments: 1. If you are above 100 billion, you are probably dropping the the 'fractions' and dealing with whole numbers. Most databases don't have their columns configured as Decimal(64,64) for 128 digits. It's not practical. So I would store the amounts above 100 billion in another value - the billions unit. And if you are 100s of billion, I am pretty certain you're not…

Any ideas on handling Ethereum gas, which is uint256?
Post reply on HN