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

51–60 of 422 posts

Re: 0.30000000000000004

#51

Post by kps »

ufo wrote: post #33

One small tip about printf for floating point numbers. In addition to "%f", you can also print them using "%g". While the precision specifier in %f refers to digits after the decimal period, in %g the precision refers to the number of significant digits. The %g version is also allowed to use exponential notation, which often results in more pleasant-looking output than %f. printf("%.4g", 1.125e10) --> 1.125e+10 print…

And %e always uses exponential notation. Then there's %a, which can be exact for binary floats.

Re: 0.30000000000000004

#52

Post by munchbunny »

_bxg1 wrote: post #40
miketuritzin wrote: post #21

Earlier quoted context omitted.

Reminds me of this Inigo Quilez article on experimenting with rendering using rational numbers: https://iquilezles.org/www/articles/floatingbar/floatingbar....

I actually ran into a bug recently while implementing my first raytracer, where the point calculated from the sphere-intersect test would just occasionally end up inside the sphere due to floating point imprecision, so the diffuse sample rays would have their origins completely in the dark, leading to randomly black pixels. Solved it by bumping every intersection out by 0.01 in the direction of its normal. And then o…

That's really interesting - hadn't thought of that before. To fix that, would you be able to do a square of the magnitude comparison with the radius and just bump the borderline cases, or is it more efficient without the extra branching?

Re: 0.30000000000000004

#53

Post by amyjess »

One of my favorite things about Perl 6 is that decimal-looking literals are stored as rationals. If you actually want a float, you have to use scientific notation.

Edit: Oh wait, it's listed in the main article under Raku. Forgot about the name change.

Re: 0.30000000000000004

#54

Post by acqq »

gowld wrote: post #45
acqq wrote: post #27

Earlier quoted context omitted.

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.

> It's not important to most people

One can argue that nothing is important to most people.

The correct calculations involving money, up to the last cent, are in fact important for people who do them or who are supposed to use them. I've implemented them in the software I've made to preform some financial stuff even in eighties, in spite of all the software which used binary floating point routines. And, of course, from the computer manufacturers, at least IBM cares too:

https://www.ibm.com/support/pages/decimal-floating-point-use...

Apparently, there are even processors which supports these formats in hardware. It's just still not mainstream.

Re: 0.30000000000000004

#55

Post by amelius »

snickerbockers wrote: post #49
amelius wrote: post #34

Earlier quoted context omitted.

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

From the article:

> Programmable calculators manufactured by Texas Instruments, Hewlett-Packard, and others typically employ a floating-point BCD format, typically with two or three digits for the (decimal) exponent.

Re: 0.30000000000000004

#56

Post by ryandrake »

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.

Wait, an entire office (presumably full of programmers) didn’t understand floating point representation? What office was this? Isn’t this topic covered first in every programming book or course where floating point math is covered?

Re: 0.30000000000000004

#57

Post by Athas »

lelf wrote: post #42

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

Exactly what are the rules for the "special comparison" in APL? That sounds horrifying to me.

Re: 0.30000000000000004

#58

Post by dunham »

Interesting, I searched for "1.2-1.0" on google. The calculator comes up and it briefly flashes 0.19999999999999996 (and no calculator buttons) before changing to 0.2. This happens inconsistently on reload.

Re: 0.30000000000000004

#59

Post by amyjess »

masklinn wrote: post #41
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 fi…

> Few or none have made it the default because they're ignominiously slower than binary floating-point.

You can strike the "none". Perl 6 uses rationals (Rat) by default, someone once told me Haskell does the same, and Groovy uses BigDecimal.

Re: 0.30000000000000004

#60

Post by leetcrew »

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

it's also a range-storage trade-off. if you use two fixed width integers to represent a rational, the minimum and maximum values are the same as that of the integer type. floating point gives a far wider range for the same number of bits.
Post reply on HN