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

341–350 of 422 posts

Re: 0.30000000000000004

#341

Post by lmilcin »

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.

It does not matter. When you are doing accounting you are supposed to be able to sum large collections of numbers and get the same result regardless of the order.

That's something FP does not provide and it makes it completely unusable for accounting.

Re: 0.30000000000000004

#342

Post by boomlinde »

jjeaff wrote: post #247
jsjohnst wrote: post #207

Earlier quoted context omitted.

For a brief time in 2008, 1 Zimbabwe dollar was very roughly equivalent to one TRILLIONTH of a United State penny. So technically a value of “1” did exist, but it was meaningless. I have some of the 100 Trillion Dollar notes from Zimbabwe from that time period.

I also have a few. You could buy a stack of 100 trillion dollar bills few a few bucks then. They are now selling for $50-$60 on eBay.

Investing in ZWL, bold move!

Re: 0.30000000000000004

#343

Post by garyclarke27 »

Postgresql figured this out many years ago with their Decimal/Numeric type. It can handle any size number and it performs fractional arithmetic perfectly accurately - how amazingly for the 21st Century! Is comically tragic to me that all of the mainstream programming languages are still so far behind, so primitive that they do not have a native accurate number type that can handle fractions.

Re: 0.30000000000000004

#344

Post by lmilcin »

chrisseaton wrote: post #290
lmilcin wrote: post #277

Earlier quoted context omitted.

I develop accounting software for banks, brokerage houses and likes. Currency, taxes, rebates, etc. handling is NEVER done with floating point. Whatever you do with money you need predictable, reproducible results. It is norm that calculations are checked by software at two companies on both sides of transaction. Any discrepancies are alarms, bug reports, unhappy customers. Every significant operation is exactly spec…

> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. 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.

I did not say floats are random. But when you do accounting you need to be able to sum large sets of numbers and compare results with another sum of different numbers and the sum must match. This just does not work with FP.

Poor souls that use FP for accounting are scourge of the industry and source of jokes.

Re: 0.30000000000000004

#345

Post by swebs »

seppel wrote: post #196
DannyB2 wrote: post #170

Earlier quoted context omitted.

The real lesson is, no matter what base (radix) you use, floating point math is inexact. The value of floating point is that it can represent extremely huge or extremely infinitesimal values. If you're working with currency / money, floating point is the wrong thing to use. For the entire history of human civilization, currency has always been an integer type, possibly with a fixed decimal point. Money has always bee…

> The real lesson is, no matter what base (radix) you use, floating point math is inexact. This is just not true. If you add 1.5 + 4.25 with IEEE754, there is nothing inexact or rounded. That you cannot exactly represent 0.1 in base2 FP is a problem of base2, not FP. You get inexact results with FP math for underflows, overflows, or if you don't have enough precision for the result (or an intermediate result). But th…

A 32 bit floating point number can only have around 4 billion unique values, yet must represent numbers from 10^38, to very small decimals. 99.99999% of numbers in this range cannot be accurately represented in floating point form.

Compare that to a 32 bit integer, which can have 4 billion unique values, and supports numbers from 0 to 4 billion. It's a 1:1 mapping.

Re: 0.30000000000000004

#346

Post by chrisseaton »

lmilcin wrote: post #344
chrisseaton wrote: post #290

Earlier quoted context omitted.

> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. 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.

I did not say floats are random. But when you do accounting you need to be able to sum large sets of numbers and compare results with another sum of different numbers and the sum must match. This just does not work with FP. Poor souls that use FP for accounting are scourge of the industry and source of jokes.

That's what I used to think, then I met these banking types, and they told me 'no we understand their semantics and we use them correctly and we know it is safe for our programs.' These teams have compiler experts on them - they aren't ignorant.

Re: 0.30000000000000004

#347

Post by boomlinde »

otabdeveloper4 wrote: post #322
zelly wrote: post #243

Earlier quoted context omitted.

Currency in banking is handled with bigints. Not rationals, just bigints of the smallest unit (i.e., 1 cent). This forces you to order operations so that divisions are done last or not at all.

The bigint you describe is just a poor man's rational, given that no computer architecture or mainstream language support them natively.

Well, you could look at it as x/100 rationals representing a dollar value. But you could also look at it as an integer amount of a smaller unit (cents). The difference is insignificant; computers support it natively.

Re: 0.30000000000000004

#348

Post by apaprocki »

joppy wrote: post #315
mcv wrote: post #20

The big issue here is what you're going to use your numbers for. If you're going to do a lot of fast floating point operations for something like graphics or neural networks, these errors are fine. Speed is more important than exact accuracy. If you're handling money, or numbers representing some other real, important concern where accuracy matters, most likely any number you intend to show to the user as a number, f…

Hear, hear! It would be great if javascript had any integral type that we could build decimals, rationals, arbitrarily-large integers and so on off. It’s technically doable with doubles if you really know what you’re doing, but it would be so much easier with an integral type.

ES does have an arbitrarily large integer type, BigInt.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: 0.30000000000000004

#349

Post by lmilcin »

chrisseaton wrote: post #346
lmilcin wrote: post #344

Earlier quoted context omitted.

I did not say floats are random. But when you do accounting you need to be able to sum large sets of numbers and compare results with another sum of different numbers and the sum must match. This just does not work with FP. Poor souls that use FP for accounting are scourge of the industry and source of jokes.

That's what I used to think, then I met these banking types, and they told me 'no we understand their semantics and we use them correctly and we know it is safe for our programs.' These teams have compiler experts on them - they aren't ignorant.

I started working on accounting software in 2002 and right now work for Citi. Compiler experts in accounting? If you are doing HFT you are not doing accounting. Accounting is what happens later when all those transactions need to actually be accounted for and balance calculated

Re: 0.30000000000000004

#350

Post by Thiez »

recursive wrote: post #214
usr1106 wrote: post #137

Earlier quoted context omitted.

Right, it is not correct. But many programs do it wrong. If you just do a couple of additions the problem will never be noticed. It's easy to write a program that sums up 0.01 until the result is not equal to n * 0.01. Not at my computer now, so I can't do it again. I remember n was bigger to be relevant for any supermarket cashier. But of course applications exist where it matters.

But it is correct. > It's easy to write a program that sums up 0.01 until the result is not equal to n * 0.01. It's not easy to do that if you use a floating point decimal type, like I recommended . For instance, using C#'s decimal, that will take you somewhere in the neighborhood of 10 to the 26 iterations. With a binary floating point number, it's less than 10.

That is simply not true. The C# decimal type doesn't accumulate errors when adding, unless you exceed its ~28 digits of precision. E.g. see here: https://rextester.com/RMHNNF58645
Post reply on HN