51–55 of 55 posts
"Nothing brings fear to my heart more than a floating point number." Gerald Jay Sussman.
[0] https://www-sop.inria.fr/indes/fp/Bigloo/doc/r5rs-9.html#Num...
[1] https://www.deinprogramm.de/sperber/papers/numerical-tower.p...
Earlier quoted context omitted.
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.
>They were fixed point, but one of the earliest things that I did (at Turing’s request) was to program a set of subroutines for doing floating-point arithmetic.
So we ought to scale to better ourselves with self-study, meanwhile one of the first errands TURING send WILKINSON on was to rid themselves of this duty. ;)
Earlier quoted context omitted.
I have a linter in my code that shouts at me if I use exact equality for floats. But I regret not making an exception for the constant zero, because it's one of the cases where you probably should accept it. I.e. if (f != 0.0) {...}
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."
if (f == 0.0) means "is f exactly zero so it's not initialized" 99 times for every one time it means "is f zero-ish because of a cancellation/degeneracy/whatever"
I just found that I have now annotated it for "yeah this one is ok" about 100 times, and caught zero cases where I meant to do a comparison to zero-or-very-nearly-so but accidentally wrote == 0.0.
So my conclusion is: I would have had less noise in my code with that exception in the linter, and the linter had been equally useful.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
That's hilarious. It's like slicing off the top 0.0001% of mt. Everest and saying that you have evenly split the world.
It gets WORSE. Here's a quote from “The Birth of a Computer” in BYTE Magazine, February 1985, an interview with J.H. Wilkinson, noted numerical slouch, on the Manchester machines ca 1949 (p. 178): >They were fixed point, but one of the earliest things that I did (at Turing’s request) was to program a set of subroutines for doing floating-point arithmetic. So we ought to scale to better ourselves with self-study, mean…
It's interesting how many of these things we take for granted.
I'm working (and have been for a while) on something that requires both ridiculous precision and speed on a relatively puny power budget and it's been a really nice trip down memory lane regarding optimization. I discovered fixed point pretty early in my programming career when doing 3D graphics on the 6502. I never imagined that that knowledge would come in handy more than almost five decades later, but here we are.