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

331–340 of 422 posts

Re: 0.30000000000000004

#331

Post by jgtrosh »

NohatCoder wrote: post #329
School-Cotton wrote: post #84

Earlier quoted context omitted.

Decimal numbers are not conceptually any more or less exact than binary numbers. For example, you can't represent 1/3 exactly in decimal, just like you can't represent 1/5 exactly in binary. When handling money, we care about faithfully reproducing the human-centric quirks of decimal numbers , not "being more accurate". There's no reason in principle to regard a system that can't represent 1/3 as being fundamentally…

Money are really best dealt with as integers, any time you'd use a non-integer number, use some fixed multiple that makes it an integer, then divide by the excess factor at the end of the calculation. For instance computing 2.15% yearly interest on a bank account might be done as follows: DaysInYear = 366 InterestRate = 215 DayBalanceSum = 0 for each Day in Year DayBalanceSum += Day.Balance InterestRaw = DayBalanceSu…

Sounds like fractions cleanly describe what you're saying?

But that practically holds only for a reasonable amount of simple arithmetics. Fractional components tend to grow exponential for many numerical methods repeated multiple times. This can happen if you're describing money and want to apply a complex numerical method from an economics article for whatever purpose. Might be worth it but be careful not to carry ever expanding fractions in your system.

Re: 0.30000000000000004

#332

Post by chrisseaton »

throwawaymath wrote: post #298
mynegation wrote: post #296

Earlier quoted context omitted.

I write real banking code. There is definitely a banking code that uses floats, e.g. valuation of financial instruments. The parent comment talks about software that does transactions and “simpler” calculations, like taxes and fees etc. When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).

> When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z). Good example of this, in Python 3: >>> (0.1 + 0.2) + 0.3 0.6000000000000001 >>> 0.1 + (0.2 + 0.3) 0.6

Every single time you run those two statements, you’ll get the same result. Yes they're non-associative. But that's specified and documented. That's not the same thing as non-deterministic in any way.

Re: 0.30000000000000004

#333

Post by boomlinde »

ezrast wrote: post #268
piadodjanho wrote: post #245

Earlier quoted context omitted.

I think the "floating point are bad for storing currencies" is one of the most common misconception about floating point. Most people don't realize that the IEEE-754 single precision floating point represent real numbers with 9 decimal digits (or 23 binary digits). The double, on the other hand, represents the real numbers with 17 decimal digits. This means that the double error UPPER BOUND is (0.00000000000000001)/2…

World GDP is around 87 trillion dollars. $ ruby -e 'pp 87e12 + 0.01' 87000000000000.02 If you're certain that your software will never handle national-economy-scale or hyperinflationary use cases, then sure, you may be able to get away with 64-bit floats, but I think "no need to worry" is overstating your case. Please do worry about precision until you've proven you don't need to.

You probably want some smaller unit than a dollar for currency as well, in which case it becomes of a problem with even smaller amounts.

I really see no reason to use any other representation for currency than decimal fixed point. Store the amount as mils or whatever unit suits your use case.

Re: 0.30000000000000004

#334

Post by NohatCoder »

jgtrosh wrote: post #331
NohatCoder wrote: post #329

Earlier quoted context omitted.

Money are really best dealt with as integers, any time you'd use a non-integer number, use some fixed multiple that makes it an integer, then divide by the excess factor at the end of the calculation. For instance computing 2.15% yearly interest on a bank account might be done as follows: DaysInYear = 366 InterestRate = 215 DayBalanceSum = 0 for each Day in Year DayBalanceSum += Day.Balance InterestRaw = DayBalanceSu…

Sounds like fractions cleanly describe what you're saying? But that practically holds only for a reasonable amount of simple arithmetics. Fractional components tend to grow exponential for many numerical methods repeated multiple times. This can happen if you're describing money and want to apply a complex numerical method from an economics article for whatever purpose. Might be worth it but be careful not to carry e…

This only for dealing with actual money, generally our banking systems have rounding rules that prevent the fractions from getting out of hand.

If you are running an economic simulation you generally don't have to worry about rounding, the whole thing is only approximate anyway.

Re: 0.30000000000000004

#335

Post by boomlinde »

piadodjanho wrote: post #245
School-Cotton wrote: post #198

Earlier quoted context omitted.

I think you mean that storing money in floating point is always terrible for accounting . Not all of finance is accounting. Imagine you work at a hedge fund, and you have a model that predicts the true value of some option. Assume the option is trading for $3.00. You do not really care if your model spits out $3.5 or $3.5000000001, you are going to buy either way. And your model probably involves a bunch of transcend…

I think the "floating point are bad for storing currencies" is one of the most common misconception about floating point. Most people don't realize that the IEEE-754 single precision floating point represent real numbers with 9 decimal digits (or 23 binary digits). The double, on the other hand, represents the real numbers with 17 decimal digits. This means that the double error UPPER BOUND is (0.00000000000000001)/2…

Fun, tangential anecdote:

I worked with a CSV containing, among other things, phone numbers. A coworker called and complained that the phone numbers were all wrong. He'd edited the thing in MS Excel, which promptly converted the phone numbers to floating point with a loss in precision. When he saved it, those new numbers were happily written back to the disk.

Re: 0.30000000000000004

#338

Post by mcv »

seppel wrote: post #230
School-Cotton wrote: post #202

Earlier quoted context omitted.

I think what that commentator meant is that floating-point math is not an accurate model of rational-number arithmetic, not that there aren't certain computations that are in fact exact. (As you point out, there are: 1.5 + 4.25 is indeed exact)

> is that floating-point math is not an accurate model of rational-number arithmetic Well, this is true. But integer math is also not an accurate model of rational-number arithmetic, yet nobody would claim that integer math is inexact.

I think the big difference is that integers are accurate within a well-defined range, in a way that's easy to understand. Floating points work within a much larger range, but are inaccurate in most of that range, and it's harder for people to understand why.

Re: 0.30000000000000004

#339

Post by tsimionescu »

chrisseaton wrote: post #327
tsimionescu wrote: post #323

Earlier quoted context omitted.

> Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result. That's not exactly true in real hardware, or at least it wasn't until ~10 years ago. With the x87 FPU, internal precision was 80 bits, while the x86 registers were at most 64 bits. So, depending on the way the program would transfer data between the CPU and FPU you…

In a language like Java, all these factors are specified and fully deterministic.

True, that's a good point. I was thinking of C & C++, but you're right, newer languages do a much better job of specifying and controlling this behavior.

Wonder if JS does something similar or not.

Re: 0.30000000000000004

#340

Post by lmilcin »

chrisseaton wrote: post #332
throwawaymath wrote: post #298

Earlier quoted context omitted.

> When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z). Good example of this, in Python 3: >>> (0.1 + 0.2) + 0.3 0.6000000000000001 >>> 0.1 + (0.2 + 0.3) 0.6

Every single time you run those two statements, you’ll get the same result. Yes they're non-associative. But that's specified and documented. That's not the same thing as non-deterministic in any way.

Yet, in accounting, you are expected to be able to sum a set of numbers in different ways and still get the same result
Post reply on HN