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

61–70 of 73 posts

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

#61

Post by zapzupnz »

matt4077 wrote: post #48
pjmlp wrote: post #35

Earlier quoted context omitted.

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”.

One wonders if the language had been invented at Apple, might the Rob have tried to name it 'Ap'.

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

#62

Post by miohtama »

andreygrehov wrote: post #60
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?

Gas is limited by having per block gas usage limit. One block cannot consume more than 8M gas.

Uint256 comes from the fact that it is native word size for EVM and that is because of crypto operations.

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

#63

Post by robaho »

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…

Also, at least in Go, it is fairly trivial to do:

type Billions fixed.Fixed

and then add operators to allow Fixed to be added, String() would add a B at the end etc. So 0.1 is 100 million, etc.

Like I said, if you are summing into the billions, you are probably not concerned about .00001 pennies

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

#64

Post by robaho »

andreygrehov wrote: post #60
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?

not really, except that all of them are going to zero, so fixed.Fixed should be sufficient :)

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

#65

Post by robaho »

OskarS wrote: post #42
tapirl wrote: post #40

Earlier quoted context omitted.

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 po…

As a long ago game developer, we never used floating point - I'm sure things have changed now - but we always used fixed point integer, with lookup tables for sin, etc.

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

#66

Post by zerealshadowban »

Hypothesis: eventually all programming languages either add a library for fixed-place decimal maths, or revise the language to take care of it.

Ada had proper fixed point types in 1983 already, and added additional requirements for the implementation of decimal fixed point types as part of the 1995 language revision. Other languages ... may benefit from its example.

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

#67

Post by tapirl »

OskarS wrote: post #42
tapirl wrote: post #40

Earlier quoted context omitted.

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 po…

The author can claim anything. But sorry, it is really not suitable for trading financial systems.

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

#68

Post by robaho »

tyingq wrote: post #3
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?

It appears to be using this: https://engineering.shopspring.com/decimal-an-arbitrary-prec...

No, original go-trader used it, since quuckfixgo uses it, and during profiling it showed as a significant cost, so I wrote Fixed.Fixed

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

#69

Post by JoeAltmaier »

paulie_a wrote: post #44
JoeAltmaier wrote: post #28

Earlier quoted context omitted.

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.

Yes it doesn't match the ad-hoc stuff finance people do. That's in fact my point.

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

#70

Post by JoeAltmaier »

dmoy wrote: post #50
JoeAltmaier wrote: post #28

Earlier quoted context omitted.

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 hyperin…

A double has 15 digits. Which counts more money than exists anywhere added up. Not a problem I'm thinking?
Post reply on HN