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

91–100 of 422 posts

Re: 0.30000000000000004

#91

Post by larrik »

recursive wrote: post #75
_y5hn wrote: post #67

Earlier quoted context omitted.

It's actually in use in many places, for things like handling currency and money, and for when you get funny corner cases involving rounding such numbers and pooling the change. Whenever I see someone handling currency in floats, something inside me wither and die a small death.

Currency handling is almost never done with rationals (numerator and denominator) and is frequently (and correctly so!) done with fixed or floating point decimal types.

This is false. It's not correct to handle currency with floating point types.

Re: 0.30000000000000004

#93

Post by lelf »

Athas wrote: post #57
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.

Assume the values could be equal if the relative error of the operation is greater than a small predefined value (called “⎕ct”, comparison tolerance, and you can change it).

Re: 0.30000000000000004

#94

Post by saagarjha »

School-Cotton wrote: post #89
saagarjha wrote: post #77

Earlier quoted context omitted.

Except when, you know, you can’t.

Curious, when can't you? My mental model of floating-point types is that they are useful for scientific/numeric computations where values are sampled from a probability distribution and there is inherently noise, and not really useful for discrete/exact logic.

Right; for the former integer arithmetic won't do.

Re: 0.30000000000000004

#96

Post by LanceH »

bwilliams18 wrote: post #87
_bxg1 wrote: post #79

Earlier quoted context omitted.

I haven't worked in fintech but I've read that money is often represented (at least in storage) as plain integers, since for example US currency only ever goes to two decimal places. But I guess once you start operating on it you run into potential truncation unless you use rationals.

US currency can go to more than two decimal places... http://blogs.reuters.com/ben-walsh/2013/11/18/do-stocks-real... I guess it's time for someone to write an "Assumptions Programmers make about money" post.

1. Money in a brokerage account is not US currency.

Re: 0.30000000000000004

#97

Post by erik_seaberg »

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

IEEE floats are pretty complicated, but today’s CPUs have dedicated support for those and not for rationals, so we use them where we probably shouldn’t.

Re: 0.30000000000000004

#98

Post by maltalex »

monster_group wrote: post #83
_bxg1 wrote: post #79

Earlier quoted context omitted.

I haven't worked in fintech but I've read that money is often represented (at least in storage) as plain integers, since for example US currency only ever goes to two decimal places. But I guess once you start operating on it you run into potential truncation unless you use rationals.

>>...since for example US currency only ever goes to two decimal places That is not correct. Stock settlement transactions often list four decimal places.

> Stock settlement transactions often list four decimal places.

That's not a significant difference compared to two decimal places, so brundolf's point still stands. There's no need for arbitrary precision.

Just store all dollars in PIPs so 5$ will be stored as 50000.

Re: 0.30000000000000004

#99

Post by erikwiffin »

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

Thanks for the suggestion. I've updated the text.

Re: 0.30000000000000004

#100

Post by pmarreck »

saagarjha wrote: post #74
pmarreck wrote: post #63

IEEE floating-point is disgusting. The non-determinism and illusion of accuracy is just wrong. I use integer or fixed-point decimal if at all possible. If the algorithm needs floats, I convert it to work with integer or fixed-point decimal instead. (Or if possible, I see the decimal point as a "rendering concern" and just do the math in integers and leave the view to put the decimal by whatever my selected precision…

IEEE is deterministic and (IMO) quite well thought-out. What specifically do you not like about it?

The fact that the most trivial floating-point addition of 0.1 + 0.2 = 0.300000000000004 was insufficient to make this seem HUMAN-nondeterministic to you? (I mean sure, if you thoroughly understood the entire spec, you might not be surprised by this result, but many people would be! Otherwise the original post and website would not exist, no?)

It’s kind of a hallmark of bad design when you have to go into a long-winded explanation of why even trivial use-case examples have “surprising” results.

Post reply on HN