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

Floats Are Weird

a.exozy.me

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Floats Are Weird

#51

Post by aragilar »

cgadski wrote: post #23

That's a neat trick, "cancelling" out catastrophic cancellation. Of course it doesn't work anymore once x is smaller than machine epsilon, whereas expm1(x) / x will continue to work. In general herbie is pretty good at suggesting the right functions / rearrangements. For this example, it finds expm1: https://herbie.uwplse.org/demo/378a0682ec4d3e735c790a58fa97e...

That doesn't surprise me, as before floats are involved you need to transform the series into something you can compute (doing this by hand is a good way to understand what's going on underneath).

https://developers.redhat.com/blog/2015/01/02/improving-math... gives a basic intro to how these functions are actually implemented, and we can if you compute exp(x) - 1 near 0 that 1 + (small stuff) - 1 is always going to be a problem (it'd be nice if we had a sufficiently smart compiler that could understand how to inline these things, but then it'd probably do surprising things as well).

Re: Floats Are Weird

#52

Post by zokier »

pierat wrote: post #45

Hotter take: Floats are bad and shouldn't be used. It's clear that even experienced programmers do NOT understand how they work, how they don't work, and the pile of edge cases. Use something saner, like binary coded decimal, larger types, and use floats as a last and very approximate resort.

As if even experienced programmers understand anything about numerics, regardless of number format used. And all numbers have pitfalls, reals are not representable on computers, not all reals are even computable. Floats at least are well-documented and predictable, and there is 30+ years of literature on how to do error analysis for them.

Re: Floats Are Weird

#53

Post by danhau »

user3939382 wrote: post #2

I’ve had weird float bugs that I didn’t have time for and fixed by operating on them as strings. Nowadays I’ve found pretty good libraries in common languages designed to handle the weird edges.

What libraries can you recommend?

Re: Floats Are Weird

#54

Post by masklinn »

Joker_vD wrote: post #42
masklinn wrote: post #34

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…

> At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with. But 0.1 + 0.2 == 0.3 — if you round both sides to 2 (or however many you need) decimal points before comparing them.

And that’s a problem, now you have to round-off defensively which complexifies the code and you have to decide how often and how defensively you round things.

Plus you’ve got the added fun that fp rounding routines don’t necessarily take a rounding mode.

Re: Floats Are Weird

#55

Post by zokier »

masklinn wrote: post #50
zokier wrote: 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)…

> See above, rounding off and collecting error after every arithmetic operation is not the expected norm and what developers are taught.

Question is, is that a problem with developers or floats? :)

Ecosystem and tooling might help here, iirc that is something Kahan himself has been complaining about a lot. For example hypothetically you could have something like FP contexts or specialized high-level types where you can easily express how many digits are you expecting and the runtime/compiler would manage rounding etc so that you'd get more often correct results. Tbh that's just top of my head, and I didn't think too much about it.

But I think the question remains, how much of the problems are actually intrinsic to FP, and if you did actually cross t's and dot i's then would there still be some intractable problems in using FP with money? So is the problem "just" that FP can easily be misused, or that its impossible to use correctly?

I want to emphasize that I do not recommend anyone go using FP for money now. I'm just curious because its something I don't fully understand and well, HN has smart people that can hopefully help me there.

Re: Floats Are Weird

#56

Post by mglz »

smallnamespace wrote: post #27
gonzus wrote: 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.

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?

Re: Floats Are Weird

#57

Post by aleph_minus_one »

masklinn wrote: post #34
zokier wrote: 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…

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

Re: Floats Are Weird

#58

Post by aleph_minus_one »

lionkor wrote: post #19
gonzus wrote: 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.

Is it fraud to willingly/knowingly use floats for money?

Sometimes (for example in models of finance or insurance markets) there do exist good reasons to use floating-point numbers for money.

Re: Floats Are Weird

#59

Post by [deleted] »

stabbles wrote: post #15
the-Black-Dread wrote: post #5

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.

Basically - don't subtract almost equal numbers - don't add numbers of vastly different magnitudes

[deleted]

Re: Floats Are Weird

#60

Post by [deleted] »

zokier wrote: post #55
masklinn wrote: post #50

Earlier quoted context omitted.

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

> See above, rounding off and collecting error after every arithmetic operation is not the expected norm and what developers are taught. Question is, is that a problem with developers or floats? :) Ecosystem and tooling might help here, iirc that is something Kahan himself has been complaining about a lot. For example hypothetically you could have something like FP contexts or specialized high-level types where you c…

[deleted]
Post reply on HN