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

41–50 of 73 posts

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

#41

Post by Const-me »

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.

> If I am owed 2.575% on $3425956.57 for 245 months, why not get the correct sum

Explosion of storage space and computation complexity. When you combine real-world numbers with compound interest, every time you add the interest, you’re adding decimal digits to the value. For your example, after 245 months of compound interest at 2.575% per month, the value will have 1228 decimal digits in it, that’s more than 512 bytes to store and process.

Another reason is, for the last ~700 years, finance folks use this: https://en.wikipedia.org/wiki/Double-entry_bookkeeping_syste... With that system, coins allow for some kind of rolling checksum verification. BTW, in modern software, the coin is often $/€/whatever 0.0001.

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

#42

Post by OskarS »

tapirl wrote: post #40
OskarS wrote: post #9

Earlier quoted context omitted.

Probably not high priority in financial computing.

No, this lib is not suitable for financial computing. It might be good for game development.

The github page comes right out and says "[it] is ideally suited for high performance trading financial systems". Clearly, that's the intention behind the library.

This would be essentially useless in game development (which is my field). In gamedev it's pretty much 32-bit floats all the way down, and very little else. Very small fixed point types are occasionally used in shaders (Cg provides a native 12-bit fixed point type) to represent colors, but a library like this is pretty much pointless.

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

#43

Post by jandrese »

JoeAltmaier wrote: post #33
toolslive wrote: post #30

Earlier quoted context omitted.

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.

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.

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

#44

Post by paulie_a »

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.

If you are using floats in financial transactions you are doing it incredibly wrong. Never use floating points for that, ever. It is insanely problematic and bug prown.

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

#45

Post by null_content »

sigzero wrote: post #29
pjmlp wrote: post #10

Dear moderators it is called Go, from the github description, "fixed decimal place math library for Go".

"Go" was such a poor language name choice, it pretty much goes by "Golang" to make it easier to search, etc.

Funny that you bring that up:

https://en.wikipedia.org/wiki/Go_(programming_language)#Nami...

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

#46

Post by 75dvtwin »

speps wrote: post #2

I'm not an expert but a finance library without a choice of rounding modes and using floating point for division and multiplication is a bit strange? Why those decisions?

In complex billing systems (that are also often responsible for computing non-trivial taxes), using fixed point math with configurable rounding rules -- is a must.

There are requirement time discussions/rules that indicate if a computation has a rounding rule or not (and it is normally driven by whether a calculation involves division, or if a computation must match an amount in a different currency).

Dividing amounts, as example, always comes about when there are mid-cycle cancelation/onboardings to a service.

Currency translations cause that as well.

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

#47

Post by stcredzero »

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.

The thing is, laws and regulations around finance and things like gas/petroleum delivery scheduling predate electronic 32 bit computers with floating point math.

This used to cause problems at a former workplace, because the "math" in the regulations around scheduling used tables, so the functions were highly non-linear, and less math savvy customers would complain that reversals of calculations wouldn't work as expected. If we had used continuous functions, it would have worked out, but then we would have been going against regulations.

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

#48

Post by matt4077 »

pjmlp wrote: post #35
pstuart wrote: post #26

Earlier quoted context omitted.

Golang is the accepted label used for titles and other communications for disambiguations. Note the domain name that hosts the project.

A domain name is not a programming language name, oh look this cool stuff I have done in ISOCPP. You can watch Rob Pike publicly correcting someone at the end of his "Go 2 Draft Specifications" session during Q&A. https://www.youtube.com/watch?v=RIvL2ONhFBI

Golang Golang Golang Golang

...and nothing bad happens.

Maybe Bob should have thought of a better name instead of trying to become the least successful prescriptionist since that guy insisting it’s “thou”, not “you”.

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

#49

Post by Finster »

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.

And in the cryptocurrency space, we need way more than 7 decimal places.

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

#50

Post by dmoy »

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.

That's not how floating point works though. The precision is by definition floating. With a sufficiently large number, your least significant bit of precision might be in the 10s or 100s or more of dollars (or whatever currency).

Your issue then is that if you combine a large enough number with anything, then you get precision loss and money just starts disappearing (or appearing out of nowhere).

Even if your hyperinflation was over ten orders of magnitude less bad than Zimbabwe's (decimal orders of magnitude even), you would run into floating point precision loss with a 64 bit floating point number.

Post reply on HN