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

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

41–50 of 422 posts

Re: 0.30000000000000004

#41

Post by masklinn »

Ididntdothis wrote: post #6

I still remember when I encountered this and nobody else in the office knew about it either. We speculated about broken CPUs and compilers until somebody found a newsgroup post that explained everything. Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

> Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

Pretty much all languages have some sort of decimal number. Few or none have made it the default because they're ignominiously slower than binary floating-point. To the extent that even languages which have made arbitrary precision integers their default firmly keep to binary floating-point.

Re: 0.30000000000000004

#42

Post by lelf »

That’s only formatting.

The other (and more important) matter, — that is not even mentioned, — is comparison. E. g. in “rational by default in this specific case” languages (Perl 6),

  > 0.1+0.2==0.3
  True
Or, APL (now they are floats there! But comparison is special)

      0.1+0.2
  0.3
      ⎕PP←20 ⋄ 0.1+0.2
  0.30000000000000004
      (0.1+0.2) ≡ 0.3
  1

Re: 0.30000000000000004

#43

Post by _bxg1 »

Koshkin wrote: post #32
_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

But rationals are more expensive to compute with (compared to floating-point; this is another example of the trade-off between performance and accuracy.)

Yeah, I assumed as much. I wasn't really thinking about that at the time, but knowing now that it exists in the wild, the only conceivable reason for it not to be used everywhere would be some kind of performance penalty.

Re: 0.30000000000000004

#44

Post by headmelted »

jonny_eh wrote: post #36

> It's actually pretty simple The explanation then goes on to be very complex. e.g. "it can only express fractions that use a prime factor of the base". Please don't say things like this when explaining things to people, it makes them feel stupid if it doesn't click with the first explanation. I suggest instead "It's actually rather interesting".

Ditto as I now feel stupid.

I read the rest of your reply but I also haven’t let go of the possibility that we’re both (or precisely 100.000000001% of us collectively) are as thick as a stump.

Re: 0.30000000000000004

#45

Post by gowld »

acqq wrote: post #27
Ididntdothis wrote: post #6

I still remember when I encountered this and nobody else in the office knew about it either. We speculated about broken CPUs and compilers until somebody found a newsgroup post that explained everything. Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

Decimal floating point is standardized since 2008: https://en.wikipedia.org/wiki/Decimal_floating_point#IEEE_75... But it's still not much used. E.g. for C++ it was proposed in 2012 for the first time http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n340... then revised in 2014: http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.ht... ...and... silence? https://www.reddit.com/r/cpp/comments/8d59mr/any_u…

It's not important to most people, because decimal floating point only helps if your UI precision is exactly the same as your internal precision, which almost never happens.

Seeing the occasional 0.300000000000004 is a good reminder that your 0.3858372895939229 isn't accurate either.

Re: 0.30000000000000004

#46

Post by jonny_eh »

headmelted wrote: post #44
jonny_eh wrote: post #36

> It's actually pretty simple The explanation then goes on to be very complex. e.g. "it can only express fractions that use a prime factor of the base". Please don't say things like this when explaining things to people, it makes them feel stupid if it doesn't click with the first explanation. I suggest instead "It's actually rather interesting".

Ditto as I now feel stupid. I read the rest of your reply but I also haven’t let go of the possibility that we’re both (or precisely 100.000000001% of us collectively) are as thick as a stump.

I learned it in college, but immediately forgot it after the exam. Why? It wasn't simple.

Re: 0.30000000000000004

#47

Post by contravariant »

gowld wrote: post #24
_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

"Why don't we just" because it's harder than one thinks. https://en.m.wikipedia.org/wiki/Arbitrary-precision_arithmet... and gets harder when you want exact irrationals too https://www.google.com/search?q=exact+real+arithmetic

Although this does make me wonder what happens if you round the rational once the numerator/denominator becomes too big.

But maybe that just results in all the floating point weirdness again, just not for small rationals.

Re: 0.30000000000000004

#48

Post by snickerbockers »

Ididntdothis wrote: post #6

I still remember when I encountered this and nobody else in the office knew about it either. We speculated about broken CPUs and compilers until somebody found a newsgroup post that explained everything. Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

There is no "better floating point model" because floating point will always be floating point. Fixed point always has been and always will be an option if you don't like the exponential notation.

Re: 0.30000000000000004

#49

Post by snickerbockers »

amelius wrote: post #34
maxdamantus wrote: post #25

Earlier quoted context omitted.

Unless you have a floating point model that supports arbitrary bases, you're always going to have the issue. Binary floats are unable to represent 1/10 just as decimal floats are unable to represent 1/3. And in case anyone's wondering about handling it by representing the repeating digits instead, here's the decimal representation of 1/12345 using repeating digits: 0.0[000810044552450384771162413932766302146618063993…

> Unless you have a floating point model that supports arbitrary bases See also binary coded decimals. https://en.wikipedia.org/wiki/Binary-coded_decimal

That's not a floating point.

Re: 0.30000000000000004

#50

Post by omar_a1 »

headmelted wrote: post #44
jonny_eh wrote: post #36

> It's actually pretty simple The explanation then goes on to be very complex. e.g. "it can only express fractions that use a prime factor of the base". Please don't say things like this when explaining things to people, it makes them feel stupid if it doesn't click with the first explanation. I suggest instead "It's actually rather interesting".

Ditto as I now feel stupid. I read the rest of your reply but I also haven’t let go of the possibility that we’re both (or precisely 100.000000001% of us collectively) are as thick as a stump.

To be fair, this is also done in every other STEM field, and CS is no exception.

We could all learn a lot more from each other if everything wasn't a contest all the time.

Post reply on HN