Computer languages should default to fixed precision decimals and offer floats with special syntax (eg “0.1f32”).
The status quo is that even Excel defaults to floats and wrong calculations with dollars and cents are widespread.
0.30000000000000004
261–270 of 422 posts
Re: 0.30000000000000004
#262Earlier quoted context omitted.
Because, unlike a thousandth of a dollar, those are valid amounts for real transactions. It goes without saying that half pennies are dead. A mill seems to be from the Coinage Act of 1792, which is perhaps a tad outdated.
Take two half penny coins or notes to the bank and they’ll credit your account a penny. Of course, just like with the $500 or $1000 notes, you’ll be losing money on the deal. > A mill ... is perhaps a tad outdated. Yet you use mills every time you pay for gas. Pointless in that case? Probably. Still used all the time? Certainly.
I pull the gas lever intermittently until the gal goes up but the cents don't. It takes about 5 tries, but always makes me smile that I beat the game.
Re: 0.30000000000000004
#263Earlier quoted context omitted.
It's the first result for "floating point site" on Google. Sure the domain itself is impossible to remember, but you don't have to remember the actual number, just what it stands for.
Remember filter bubble. My first result is not your first result. (although in this case it happens to be, but we both probably search a lot on programming)
> My first result is not your first result.
It would be if you both used DuckDuckGo, though :)
Re: 0.30000000000000004
#264I feel like it should really be emphasised that the reason this occurs is due to a mismatch between binary exponentiation and decimal exponentiation. 0.1 = 1 × 10^-1 , but there is no integer significand s and integer exponent e such that 0.1 = s × 2^e . When this issue comes up, people seem to often talk about fixing it by using decimal floats or fixed-point numbers (using some 10^x divisor). If you change the base,…
If you only use decimals in your application, it actually is a fix because you can store the numbers you care about in exact precision. Of course it's not really a fix if you're being pedantic but for a lot of simple UI stuff it's good enough.
Re: 0.30000000000000004
#265Earlier quoted context omitted.
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?
I just did it across the board; since the error is in the floating-point noise I don't know if I'd even trust a comparison on that. Plus, the discrepancy between "bumped" and "unbumped" samples might cause some visible artifacts.
Direct3D used to have a Z-bias for a similar problem: rendering pictures hanging on walls at a far Z depth. Their whql tests even tested for it.
It was fun discovering all the corner cases while debugging drivers.
Re: 0.30000000000000004
#266Re: 0.30000000000000004
#267Earlier 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.
When I was in college the professor of my software engineering class explicitly warned us to never use floating point numbers for money. He went on at length of the dangers of floating points for dealing with money and warned us that people can get really upset if they feel like they've been screwed out of money. He had decades of experience in the software development industry and I got the feeling that he'd seen th…
He probably thought Lumbergh did her
Re: 0.30000000000000004
#268Earlier 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…
World GDP is around 87 trillion dollars.
$ ruby -e 'pp 87e12 + 0.01'
87000000000000.02
Re: 0.30000000000000004
#269Earlier quoted context omitted.
It's not always terrible. I've seen doubles appropriately used in cases where performance was paramount, and floating point error was either not relevant or less important. That said, yeah, when working with money in situations where money matters, some sort of decimal or rational datatype should be the rule, not the exception.
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, ...
Pennies (or any equivalents) are not the smallest unit in any currency. Fractions of it are perfectly acceptable and even common.
Re: 0.30000000000000004
#270Earlier quoted context omitted.
This is false. It's not correct to handle currency with floating point types.
It's not correct, but it happens anyway, even in large ERP systems that really should know better but somehow don't.
It is correct! Using decimal types is the widely recommended way of solving this problem. That includes fixed and floating point types. The problem is using base-2 floating point types, since those are subject to the kinds of rounding errors in the OP. But decimal floating point types are not subject to these kinds of rounding errors.
But they still can't precisely represent quantities like 1/3 or pi.