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

Floating Point Math

0.30000000000000004.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Floating Point Math

#61

Post by ycombobreaker »

trinovantes wrote: post #18
svat wrote: post #15

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, program…

If nothing else, I think compilers/linters should warn when trying to use equality/comparison operators between floats since most of the time it's mathematically wrong. All of my projects are filled with isApproxEquals(float1, float2)

I see a lot of this (generic approx-comparison functions) at work. It can catch some problems, true, but it becomes very cargo-cultish. They understand that the hardware rounds calculations, but they behave as if the hardware is nondeterministic. There's also very little thought going into an appropriate epsilon value, whether based on the calculation being done, or the tolerance of the overall output/algorithm.

Re: Floating Point Math

#62

Post by ycombobreaker »

Jasper_ wrote: post #39
ketzu wrote: post #3

It's a nice website explaining the problem lightly, but I think the cool part is the encyclopedic language list handling floating point numbers and the reference for bigdecimal support. The only sentence I don't really like: > When you have a base-10 system (like ours), it can only express fractions that use a prime factor of the base. It's a weird mix of over- and under-generalization. The second half sounds like a…

My attempt: You can't express 1/3, 1/6, 1/7, or 1/9 in decimal without infinitely repeating digits; you can only express 1/2 and 1/5, and 2*5=10. In binary systems, you can only represent multiples of 1/2 without infinite repeating digits, so, 0.5, 0.25, 0.125 are all exact in binary floating point. 0.1 is 1/10, which needs that 5 you don't have in binary. Computers don't have infinite memory, so infinitely repeating…

This is pretty good for illustration to a layperson, thank you! Filling in a few other examples could be useful. For instance, why do 1/4 and 1/8 work in base-10?

I imagine you could create a table of the fractions 1/2, 1/3, ..., 1/10; prime factorization (e.g. 1/4 = 1/2 * 1/2), their decimal representation, their binary representation, and maybe for familiarity the sum-of-fractions represented by the binary representation. e.g. 0.101 meaning 1/2 + 1/8.

Re: Floating Point Math

#63

Post by everybodyknows »

nraynaud wrote: post #22

Do you have a good blog post on choosing tolerances and ranges? I just started at a company where it’s probably about now that we should get smart with that. We do geometry so the problem gets even worse.

For an example of safe geometric calculation in floating point, see Google's S2 library:

https://github.com/google/s2geometry

Re: Floating Point Math

#64

Post by lmm »

dahfizz wrote: post #58
lmm wrote: post #19

Earlier quoted context omitted.

Because that was too slow in the 1970s, when this particular corner of programming language design ossified.

Alternatively, people cared about performance then. Nowadays programmers would rather do the slow, easy thing so they don't have to think as hard.

The idea that it's somehow morally lacking to put less value on performance on machines are literally thousands of time faster than those used for early programming has always struck me as rather odd.

Re: Floating Point Math

#65

Post by Gibbon1 »

lmm wrote: post #64
dahfizz wrote: post #58

Earlier quoted context omitted.

Alternatively, people cared about performance then. Nowadays programmers would rather do the slow, easy thing so they don't have to think as hard.

The idea that it's somehow morally lacking to put less value on performance on machines are literally thousands of time faster than those used for early programming has always struck me as rather odd.

When I think of the problem what I see is the compiler pretends to be fast by forcing the programmer to deal with the problems. Bonus the solutions are inherently fragile and bug ridden. Which the programmer gets smugly blamed for.

Re: Floating Point Math

#66

Post by kaba0 »

ycombobreaker wrote: post #60
franga2000 wrote: post #49

Earlier quoted context omitted.

That doesn't really matter. Even if you had 20 years of experience in C++ or whatever, you could confidently write JavaScript code with floating point bugs in it, because "the type is called Number, obviously that isn't floating point". Beginner programmers might actually realise this sooner, since veterans aren't going to be writing console.log(0.3+0.2) as part of learning the language.

IMHO this does not follow, for a few reasons: - An experienced programmer would know that IEEE FP hardware is ubiquitous. Why would a language eschew that hardware capability by default? If anything, I would assume that any unfamiliar general-purpose language DOES start from that point (using IEEE float to represent non-integer numbers) because of historical precedent. - "Number" is about as vague as you can get for…

Should we really optimize for someone writing in a new language without reading anything about it? Like, if he/she doesn’t even know that js numbers are floats, just don’t even let them close to a program.

Re: Floating Point Math

#67

Post by ycombobreaker »

kaba0 wrote: post #66
ycombobreaker wrote: post #60

Earlier quoted context omitted.

IMHO this does not follow, for a few reasons: - An experienced programmer would know that IEEE FP hardware is ubiquitous. Why would a language eschew that hardware capability by default? If anything, I would assume that any unfamiliar general-purpose language DOES start from that point (using IEEE float to represent non-integer numbers) because of historical precedent. - "Number" is about as vague as you can get for…

Should we really optimize for someone writing in a new language without reading anything about it? Like, if he/she doesn’t even know that js numbers are floats, just don’t even let them close to a program.

No we should not, nor am I advocating for that.
Post reply on HN