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

What every computer scientist should know about floating-point arithmetic (1991) [pdf]

itu.dk

Post reply on HN
Print view View original

41–50 of 55 posts

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#41

Post by 1718627440 »

pdpi wrote: post #33
jacquesm wrote: post #11

Earlier quoted context omitted.

Absolutely nobody will think this is 'clearer', this is a leaky abstraction and personally I think that the OP is right and == in combination with floating point constants should be limited to '0' and that's it.

We all know that 1/3 + 1/3 + 1/3 = 1, but 0.33 + 0.33 + 0.33 = 0.99. We're sufficiently used to decimal to know that 1/3 doesn't have a finite decimal representation. Decimal 1/10 doesn't have a finite binary representation, for the exact same reason that 1/3 doesn't have one in decimal — 3 is co-prime with 10, and 5 is co-prime with 2. The only leaky abstraction here is our bias towards decimal. (Fun fact: "base 10"…

> Fun fact: "base 10" is meaningless, because every base calls itself base 10

Maybe we should name the bases by the largest digit they have, so that we are using base 9 most of the time.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#42

Post by 1718627440 »

Sharlin wrote: post #9
jmalicki wrote: post #8

Earlier quoted context omitted.

.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.

> 0.1 just isn't an actual number. A finitist computer scientists only accepts those numbers as real that can be expressed exactly in finite base-two floating point?

That's essentially what you already do for integer arithmetic.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#43

Post by jacquesm »

adampunk wrote: post #34
jacquesm wrote: post #12

Earlier quoted context omitted.

Fixed point gave rise to the old programmers meme 'if you need floating point you don't understand your problem'. It's of course partially in jest but there is a grain of truth in it as well.

It is quite old, attributable to VonNeumann and Goldstine in 1947. Later Goldstine joked that if rescaling for every step was easy enough for Johnny it ought to be easy for everyone else. The gag here being that perhaps that isn’t the best dividing line for programming talent.

That's hilarious.

It's like slicing off the top 0.0001% of mt. Everest and saying that you have evenly split the world.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#44

Post by hnfong »

Sharlin wrote: post #29
tux3 wrote: post #21

Earlier quoted context omitted.

0.1 is of course a real number, but let A \in R the set of actual numbers... (/s)

The funny thing is, according to infinitists real numbers are not real. But I do like the concept of the set of actual numbers.

I don't know whether I'm an infinitist, but I personally think "real numbers" is the most ingenious marketing term created by mathematicians...

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#45

Post by materialpoint »

emil-lp wrote: post #6

> 0.1 + 0.1 + 0.1 == 0.3 False I always tell my students that if they (might) have a float, and are using the `==` operator, they're doing something wrong.

Well, there are many legitimate cases for using the equality operator. Insisting someone is doing something wrong is downright wrong and you shouldn't be teaching floating-point numbers. A few use cases are: Floating-points differing from default or initial values and carrying meaning, e.g. 0 or 1 translates to omitting entire operations. Then there is also the case for measuring the tinyest possible variation when using relative tolerances are not what you want. Not exhaustive. If you use == with fp, it only means you should've thought about it thoroughly.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#46

Post by SideQuark »

emil-lp wrote: post #6

> 0.1 + 0.1 + 0.1 == 0.3 False I always tell my students that if they (might) have a float, and are using the `==` operator, they're doing something wrong.

There’s plenty of cases where ‘==‘ is correct. If you understand how floating point numbers work at the same depth you understand integers, then you may know the result of each side and know there’s zero error.

Anything to do “approximately close” is much slower, prone to even more subtle bugs (often trading less immediate bugs for much harder to find and fix bugs).

For example, I routinely make unit tests with inputs designed so answers are perfectly representable, so tests do bit exact compares, to ensure algorithms work as designed.

I’d rather teach students there’s subtlety here with some tradeoffs.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#47

Post by SideQuark »

Sharlin wrote: post #9
jmalicki wrote: post #8

Earlier quoted context omitted.

.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.

> 0.1 just isn't an actual number. A finitist computer scientists only accepts those numbers as real that can be expressed exactly in finite base-two floating point?

Yes. A computer scientist should know how numbers are represented and not expect non-representable numbers in that format to be representable.

0.1 is just as non-representable in floating point as is pi as is 100^100 in a 32 bit integer.

Terminating dyadic rationals (up to limits based on float size) are the representable values.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#48

Post by SideQuark »

emil-lp wrote: post #17
jmalicki wrote: post #8

Earlier quoted context omitted.

.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.

Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039

If they were taught what was representable and why they’d learn it quickly. And those that forget details later know to chase it down again if they need it. Making it voodoo hides that it’s learnable, deterministic, and useful to understand.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#49

Post by vikingerik »

1718627440 wrote: post #40
vikingerik wrote: post #35

Earlier quoted context omitted.

Zero shouldn't be an exception there. If f had been set from something like f = a - b, then you're in the same situation where f might be almost but not exactly zero. The linter wouldn't know where f came from, so it should flag all floating point equality cases, and have some way that you can annotate it for "yeah this one is okay."

The idea is not to do it with values derived from arithmetic, but e.g. from measurements where a real zero is very unlikely and indicates something different.

Right, but that's not something a linter could know.

Re: What every computer scientist should know about floating-point arithmetic (1991) [pdf]

#50

Post by jmalicki »

emil-lp wrote: post #17
jmalicki wrote: post #8

Earlier quoted context omitted.

.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.

Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039

(Another small note.... 1.25 * 0.1 is not representable because 0.1 is not representable, so that doesn't divide by 10)

1.25 = 2^0 + 2^-2, so is representable.

0.125 = 2^-3, so is representable

1.25 / 10.0 = 0.125 so is representable. 10.0 = 2^3 + 2^1.

1.25 * 0.1 is not representable, because 0.1 is not representable, and those low order bits show up in the multiplication

Post reply on HN