
Fixed – Fixed-place decimal math library for Go - networkimprov
https://github.com/robaho/fixed
======
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.

~~~
andreygrehov
Any ideas on handling Ethereum gas, which is uint256?

~~~
miohtama
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.

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

~~~
strainer
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.

------
speps
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?

~~~
chrisseaton
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?

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

~~~
chrisseaton
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.

~~~
jimktrains2
Predicting a value is not the same as accounting.

------
nemetroid
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).

~~~
nickcw
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](https://stackoverflow.com/q/2550281/164234)

~~~
dagss
When people consider float vs int, performance is seldom a relevant factor.

You have to ask, what do you even _mean_ if you use floating point for
representing money?

If you use floating point, the whole point is that you want the behaviour

1e100 = 1e100 + 1

This is exactly what you want for many analysis and decision making problems,
but it is a dangerous default.

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

~~~
toolslive
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.

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

~~~
jandrese
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.

~~~
justincormack
x86 still has BCD support, in 32 bit mode
[http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaa...](http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaax.htm)

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

------
black-tea
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.

~~~
PedroBatista
Where can we find your bignum library?

~~~
black-tea
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.

------
tapirl
No sqrt, sin, cos functions?

~~~
OskarS
Probably not high priority in financial computing.

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

~~~
OskarS
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.

~~~
robaho
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.

