Earlier quoted context omitted.
If it’s not possible to charge such amounts, what exactly is the point of the accuracy?
Tarsnap is prepaid.
"Tarsnap's author is a geek." ;)
0.30000000000000004
211–220 of 422 posts
Re: 0.30000000000000004
#212Earlier quoted context omitted.
Someone should tell that to everyone who ever used a ½¢ coin in the US. Also, US law explicitly states (31 USC §5101) that the unit of 1/1000th of a dollar is a mill.
> Someone should tell that to everyone who ever used a ½¢ coin in the US. All 10 of them?
I’ve got some at home, but admittedly I’d never use one as currency. I also have US ½¢ paper notes too.
Re: 0.30000000000000004
#213Earlier quoted context omitted.
Storing money in floating point is always terrible. If speed is an issue, store it in integer types representing the smallest unit in the currency, e.g. pennies. Unless you’re doing, what, massively parallel GPU algos on batches of independent amounts? But even then you could use the float as an int in that way... Honestly when is float ever actually good for money? Not for speed, not for correctness, ...
Storing money in floating point is fine. Just round to the nearest atomic unit when displaying. Sometimes this is a necessity when working with money in e.g. existing JSON APIs. You lose a few bits of range relative to fixed point storage but it's almost never a practical issue. Performing arithmetic operations against money in floating point is the dangerous part, as error can accumulate beyond an atomic unit.
> Storing money in floating point is fine. Just round to the nearest atomic unit when displaying.
Well, it's not just a display issue. In accounting, associativity and commutativity are important. People do care that `a + b + c - a == c + b` should evaluate to “true”.
Re: 0.30000000000000004
#214Earlier quoted context omitted.
This is false. It's not correct to handle currency with floating point types.
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.
Re: 0.30000000000000004
#215Earlier quoted context omitted.
Someone should tell that to everyone who ever used a ½¢ coin in the US. Also, US law explicitly states (31 USC §5101) that the unit of 1/1000th of a dollar is a mill.
Go to a bank and ask for a half penny or a thousandth of a dollar. Let me know how it goes.
Go to a bank and ask for a $500 or $1000 note too. They won’t give you one as they aren’t in circulation anymore, but most (all?) will let you deposit it for face value.
Re: 0.30000000000000004
#216Earlier quoted context omitted.
Tarsnap is prepaid.
"Tarsnap's author is a geek." ;) https://www.tarsnap.com/picoUSD-why.html
"when it internally converts storage prices from picodollars per month to attodollars per day, it rounds the prices down to benefit the customer."
A gentleman and a scholar.
Re: 0.30000000000000004
#217Earlier quoted context omitted.
This is false. It's not correct to handle currency with floating point types.
They said floating point decimal types which probably means BCD.
There are different implementations, and BCD is only one of them. Another popular one is a mantissa and exponent, but the exponent is for a 10-based shift rather than the typical floating point.
Re: 0.30000000000000004
#218I 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.
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…
> Binary floats are unable to represent 1/10 just as decimal floats are unable to represent 1/3.
That is true, but most humans in this world expect 0.1 to be represented exactly but would not require 1/3 to be represented exactly. Because they are used to the quirks of the decimal point (and not of the binary point).
This is a social problem, not a technical one.
Re: 0.30000000000000004
#219In JavaScript, you could use a library like decimal.js. For simple situations, could you not just convert the final result to a precision of 15 or less?
> 0.1 + 0.2;
(0.1 + 0.2).toPrecision(15);
Re: 0.30000000000000004
#220Earlier quoted context omitted.
If you are dealing with other people’s money, the only accurate is accurate . Close enough should not be in any financial engineer’s mindset, imho.
In this case, it's both. Decimal floating point types do not lose precision with base-10 numbers, unless using trig, square roots, arbitrary division and the like.
> arbitrary division
Like commonly happens doing financial calculations, especially doing interest calculations.