Live data from Hacker News

Floats Are Weird

a.exozy.me

71–80 of 120 posts

Re: Floats Are Weird

#71
post #56

Earlier quoted context omitted.

The rule as stated is way too strong, for example option prices are money amounts but floats are unavoidable in calculating them. For a less exotic example, consider that Excel, widely used by actual accountants, uses floats throughout to represent numbers.

> for example option prices are money amounts but floats are unavoidable in calculating them. How so? Can't you just use long integers with cents or 1/1000th of a cent?

Why would you? For most forward-looking calculations, the uncertainty of the future completely swamps any cent-rounding.

Even for plain-vanilla bond price calculations, floats are the right tool for the job. Say you have a bond that pays $5 every year for 10 years, then $100. What's that worth today?

Well, you have a forecast yield curve of interest rates. Say it's quoted as continuously compounded rates, so then you get something like price = sum_{t=1..10}($5*exp(-r(t)*t)) + $100*exp(-r(10)*10).

But wait, say you actually have 1000 different potential paths of interest rates, and you want to average over all of them.

Oh, and there's a 1% chance of default every year.

Oh, and actually these are mortgages, so there's a path-dependent chance of them refinancing every year, if the rates get low enough.

And then there's an overall economic forecast, so if you have a bunch of mortgages, there's a bigger chance they'll all default at the same time.

And so on. Rounding the cents isn't really worth the worry, once you're putting noisy forecasts through `exp` (or worse special functions).

This applies for vanilla bond valuation, any option, any future. More so if you want risk measures (what if rates go up 0.10%? volatility increases?), and so on.

Floats work just fine for this.

Re: Floats Are Weird

#72
post #26

Earlier quoted context omitted.

This gets repeated a lot, and I don't disagree. But I find odd that doubles would be so unsuitable for monetary (and other similar) arithmetic; in principle you have 15 significant digits which should be more than enough, and precise control how the results are rounded. And all the basic arithmetic should return correctly rounded values to the last ULP. So it is weird that those tools are still not good enough and it…

The problems of floats are not the number of significant digits, it’s the imprecision of the representation (floats don’t just cut off at the end), that these imprecisions compound, and that float operations are not commutative. At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with. X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 8…

> Guarding against floating-point issues or considering precision errors is neither part of school-learned arithmetics, nor of most CS programs

What the fuck? I didn't even take a CS major and we got the imprecision of floats bashed into our heads. What are CS majors being taught?

Re: Floats Are Weird

#73

Earlier quoted context omitted.

The problems of floats are not the number of significant digits, it’s the imprecision of the representation (floats don’t just cut off at the end), that these imprecisions compound, and that float operations are not commutative. At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with. X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 8…

> and that float operations are not commutative. At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with. Addition and multiplication of floating point numbers is commutative (sole theoretical exception: there principally exist multiple representations of NaNs, even though in practice processors do not make use of this freedom, i.e. in practice these floating point operations are completely commutativ…

Yes, but not associative. I guess this is what GP was trying to say (and which actually can cause issues).

Re: Floats Are Weird

#74
post #26
post #17

I decided years ago that the next time I hear someone suggesting we use floats / doubles to represent money amounts, I am going to punch them in the face.

This gets repeated a lot, and I don't disagree. But I find odd that doubles would be so unsuitable for monetary (and other similar) arithmetic; in principle you have 15 significant digits which should be more than enough, and precise control how the results are rounded. And all the basic arithmetic should return correctly rounded values to the last ULP. So it is weird that those tools are still not good enough and it…

Floats vs money is like `ascii` vs `utf-8`.

You can get a bunch of bits, but how you handle it make a ton of differences

Plus, so little languages care about us living in the business world. You can count with fingers in a single hand the languages that are meant for business app.

All the others are bad languages (and libraries, frameworks, data stores), ill-suited for the job. And so, all of them need to reimplement (badly, ad-hoc, bug-ridden) version of money and friends.

And weirdly, no hardware support at all, so our friends on C say: "Look, no important to handle money, bye" and nobody else does it either.

Re: Floats Are Weird

#76
post #47

Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact. My current approach is that I try to guess (or ask) how a customer understands or checks a statement/invoice. The customer usually takes a calculator and enters the rounded numbers they see. I then try to do all programmatic calculations exactly the same way: Operation - round - operati…

I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague.

> The system can be too exact

Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?

Re: Floats Are Weird

#77

Then what's the best way to handle these cases? Are there any set of rules we should use while implementing the mathematical equations dealing with limits in floating points.

Useful list of tricks: http://www.plunk.org/~hatch/rightway.html

I love that that page is nearly the same as it when I saw it ~20 years ago. Things things are still the right way.

Re: Floats Are Weird

#78
post #40

Earlier quoted context omitted.

> At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with That is the one example that floats around a lot, but its also imho not very good one. '0.1', '0.2', and '0.3' are not floating point values, so the premise is flawed. 0.1000000000000000055511151231257827021181583404541015625 + 0.200000000000000011102230246251565404236316680908203125 != 0.299999999999999988897769753748434595763683319091796875 i…

> That is the one example that floats around a lot, but its also imho not very good one. '0.1', '0.2', and '0.3' are not floating point values, so the premise is flawed. No, it’s the entire point. None of the values we deal with day to day are binary floating point, and certainly not currencies. So this sort of representational approximations is a major and constant issue of using floats. > Also `round(0.1 + 0.2, 15)…

> None of the values we deal with day to day

'0' is twice-defined by IEEE 754, together with ±inf and nan. They aren't very interesting values in terms of monetary transactions, though.

Re: Floats Are Weird

#79

I guess "floats are weird" is a catchier title than "numerical computing is an acquired skill based in part on understanding the various consequences of value representation density being inversely proportional to the absolute value".

It's at least nice to see somebody reasoning through where error comes from instead of just throwing up their hands as if the error was inexplicable. I agree that the title is unfortunate though.

Re: Floats Are Weird

#80

Then what's the best way to handle these cases? Are there any set of rules we should use while implementing the mathematical equations dealing with limits in floating points.

Other commenters have pointed to tricks that are undoubtedly useful, but the real answer imo is to understand where rounding error will be introduced in your problem, and where it can become catastrophic so that you can use careful alternatives in those cases.
Post reply on HN