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

Beware of Fast-Math

simonbyrne.github.io

Post reply on HN
Print view View original

111–120 of 233 posts

Re: Beware of Fast-Math

#111

Post by jcranmer »

SonOfLilit wrote: post #103
nurettin wrote: post #83

Earlier quoted context omitted.

I inherited systems that trade real world money using f64. They work surprisingly well, and the errors and bugs are almost never due to rounding. Those that are also have easy fixes. So I'm always baffled by this "expert opinion" of using integers for cents. It is pretty much up there with "never use python pickle it is unsafe" and "never use http, even if the program will never leave the subnet".

You can make money modeling buy/sell decisions in floats and then having the bank execute them, but if the bank models your account as a float and loses a cent here and there, it will be sued into bankruptcy.

A double-precision float has ~16 decimal digits of precision. Which means as long as your bank account is less than a quadrillion dollars, it can accurately store the balance to the nearest cent.

Re: Beware of Fast-Math

#112

Post by [deleted] »

simonw wrote: post #94
outurnate wrote: post #84

Earlier quoted context omitted.

You're better off representing values as rationals; a ratio between two different numbers. For example, 0.0375 would be represented as 375 over 10000, or 3 over 80

Sounds hard to model in SQLite.

[deleted]

Re: Beware of Fast-Math

#113

Post by jksflkjl3jk3 »

razighter777 wrote: post #65

The worst thing that strikes fear into me is seeing floating points used for real world currency. Dear god. So many things can go wrong. I always use unsigned integers counting number of cents. And if I gotta handle multiple currencies, then I'll use or make a wrapper class.

Floating point math shouldn't be that scary. The rules are well defined in standards, and for many domains are the only realistic option for performance reasons.

I've spent most of my career writing trading systems that have executed 100's of billions of dollars worth of trades, and have never had any floating point related bugs.

Using some kind of fixed point math would be entirely inappropriate for most HFT or scientific computing applications.

Re: Beware of Fast-Math

#114

Post by teaearlgraycold »

simonw wrote: post #94
outurnate wrote: post #84

Earlier quoted context omitted.

You're better off representing values as rationals; a ratio between two different numbers. For example, 0.0375 would be represented as 375 over 10000, or 3 over 80

Sounds hard to model in SQLite.

Two columns?

Re: Beware of Fast-Math

#115

Post by eddd-ddde »

jksflkjl3jk3 wrote: post #113
razighter777 wrote: post #65

The worst thing that strikes fear into me is seeing floating points used for real world currency. Dear god. So many things can go wrong. I always use unsigned integers counting number of cents. And if I gotta handle multiple currencies, then I'll use or make a wrapper class.

Floating point math shouldn't be that scary. The rules are well defined in standards, and for many domains are the only realistic option for performance reasons. I've spent most of my career writing trading systems that have executed 100's of billions of dollars worth of trades, and have never had any floating point related bugs. Using some kind of fixed point math would be entirely inappropriate for most HFT or scie…

How do you handle the lack of commutativity? I've always wondered about the practical implications.

Re: Beware of Fast-Math

#116

Post by nulld3v »

dataangel wrote: post #91
nurettin wrote: post #83

Earlier quoted context omitted.

I inherited systems that trade real world money using f64. They work surprisingly well, and the errors and bugs are almost never due to rounding. Those that are also have easy fixes. So I'm always baffled by this "expert opinion" of using integers for cents. It is pretty much up there with "never use python pickle it is unsafe" and "never use http, even if the program will never leave the subnet".

you can't accurately represent 10 cents with floats, 0.1 is not directly representable. same with 1 cent, 0.01. Seems like if you do and significant math on prices you should run into rounding issues pretty quickly?

I'm curious where you got this idea from because it is trivially disprovable by typing 0.1 or 0.01 into any python or JS REPL?

Re: Beware of Fast-Math

#117

Post by jcranmer »

eddd-ddde wrote: post #115
jksflkjl3jk3 wrote: post #113

Earlier quoted context omitted.

Floating point math shouldn't be that scary. The rules are well defined in standards, and for many domains are the only realistic option for performance reasons. I've spent most of my career writing trading systems that have executed 100's of billions of dollars worth of trades, and have never had any floating point related bugs. Using some kind of fixed point math would be entirely inappropriate for most HFT or scie…

How do you handle the lack of commutativity? I've always wondered about the practical implications.

Floating-point is completely commutative (ignoring NaN payloads).

It's the associativity law that it fails to uphold.

Re: Beware of Fast-Math

#118

Post by jakevoytko »

eddd-ddde wrote: post #115
jksflkjl3jk3 wrote: post #113

Earlier quoted context omitted.

Floating point math shouldn't be that scary. The rules are well defined in standards, and for many domains are the only realistic option for performance reasons. I've spent most of my career writing trading systems that have executed 100's of billions of dollars worth of trades, and have never had any floating point related bugs. Using some kind of fixed point math would be entirely inappropriate for most HFT or scie…

How do you handle the lack of commutativity? I've always wondered about the practical implications.

I asked an ex-Bloomberg coder this question once after he told me he used floating points to represent currency all the time, and his response was along the lines of “unless you have blindingly-obvious problems like doing operations on near-zero numbers against very large numbers, these calculations are off by small amounts on their least-significant digits. Why would you waste the time or the electricity dealing with a discrepancy that’s not even worth the money to fix?”

Re: Beware of Fast-Math

#119

Post by kolbe »

jksflkjl3jk3 wrote: post #113
razighter777 wrote: post #65

The worst thing that strikes fear into me is seeing floating points used for real world currency. Dear god. So many things can go wrong. I always use unsigned integers counting number of cents. And if I gotta handle multiple currencies, then I'll use or make a wrapper class.

Floating point math shouldn't be that scary. The rules are well defined in standards, and for many domains are the only realistic option for performance reasons. I've spent most of my career writing trading systems that have executed 100's of billions of dollars worth of trades, and have never had any floating point related bugs. Using some kind of fixed point math would be entirely inappropriate for most HFT or scie…

All your price field messages are sent to the exchange and back via fixed point, so you are using fixed point for at least some of the process (unless you're targeting those few crypto exchanges that use fp prices).

If you need to be extremely fast (like fpga fast), you don't waste compute transforming their fixed point representation into floating.

Re: Beware of Fast-Math

#120

Post by spookie »

cycomanic wrote: post #90
on_the_train wrote: post #52

Earlier quoted context omitted.

I worked in cad, robotics and now semiconductor optics. In every single field, floating precision down to the very last digits was a huge issue

Interesting, I stand corrected. In most of the fields I'm aware off one could easily work in 32bit without any issues. I find the robotics example quite surprising in particular. I think the precision of most input sensors is less than 16bit so. If your inputs have this much noise on them how come you need so much precision your calculations?

The precision isn't uniform across a range of possible inputs. This means you need a higher bit depth, even though "you aren't really using it", just so you can establish a good base precision you are sure you are hitting at every range. The part where you are saying "most sensors" is doing a lot of leverage here.
Post reply on HN