Live data from Hacker News

0.30000000000000004

0.30000000000000004.com

91–100 of 140 posts

Re: 0.30000000000000004

#91
post #20

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. In a way, not so simple (obvious to you? not to me)

I get angry every time I read about floating point being discussed by people who don't understand how numbers work, but I am going to try not to rant and be constructive.

Think of if this way. You can express the fraction 1/2 in decimal (0.5) and binary because 2 is evenly divisible into both 10 and 2. You can't represent 1/3 in either but you could in trinary (0, 1, 2 - it would be 0.1) Now, why programmers feel the numbers you can't represent exactly in binary are somehow worse than the ones in decimal baffles me. I guess we are just used to them and anything else seems wrong. But they are just as legitimate.

Re: 0.30000000000000004

#92

> Your language isn't broken, it's doing floating point math. Specifically, it's doing binary floating point math, which is an odd choice for decimal literals that's​ common only because very few languages choose correctness and clarity over performance when dealing with numbers, which leads to all kinds of problems with the most obvious approaches to addressing common problem domains in industrially popular language…

"If I had a dime for every time I've seen someone use FLOAT to store currency, I'd have $999.997634"

https://twitter.com/billkarwin/status/347561901460447232

Re: 0.30000000000000004

#93

It's stuff that should be a part of very beginning of any CS101. Float arithmetics != Decimal arithmetics

Only if you're trying to scare the newbies away. This stuff does need to be learned at some point but cs101 should be about getting a feel for programming in general.

Focusing on the basics of objects/classes functions (with mandatory source control) is smart before killing their will to learn with nasty edge cases

Re: 0.30000000000000004

#94
post #68

Earlier quoted context omitted.

I absolutely disagree. If you want to represent currency, for example, you should not use decimal floating point. You should integers, specifically you should use an integer number of tenths of cents, which is pretty widely agreed as the standard unit of currency in a computer (or tenths of yen, for example). You need to be extremely careful about overflow, but you need to be anyway, and should almost certainly just…

I absolutely disagree with your disagreement. Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this. Additionally please research decimal floating points before disagreeing.

> Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this.

For what it's worth, values on the order of 10^18 are exactly representable in int64; decimal64, however, only has 16 significand digits, so there you are already affected by rounding, and it's not far from where the distance between consecutive numbers is greater than 1.

In general, with floating points, you either waste lots of space for excessive precision around zero, or you quickly lose precision when numbers grow. On top of that, you get all the other quirks of floating point numbers such as cancellation.

Re: 0.30000000000000004

#95
post #75
post #73

Earlier quoted context omitted.

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

But in decimal floating point this is also solved: 1/7 + 2/7 = 3/7 Please research decimal floating point first..

That particular example happens to work, but 1/7 + 1/7 != 2/7.

DecFP is not magic. You still need to know that you're dealing with limited precision numbers under the hood.

Re: 0.30000000000000004

#96
post #73
post #56

For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard). Contrary to the "default" floating point, which are base 2 and do not support precise presentations of certain numbers, you can use a decimal floating point system which uses base 10 and therefore allows exact and precise presentation and solves the problem mentioned on the page. Also important: since…

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

This is solved by the Scheme numerical tower, which prefers exact representation​s (including exact rationals) unless inexact representation is explicitly requested or forced by an operation that doesn't support exact results.

Re: 0.30000000000000004

#97

Whenver IEEE 754 and its quirks are discussed a potential alternative (but so far without hardware support) called Unum - Universal Numbers - should not go unmentioned: https://en.wikipedia.org/wiki/Unum_(number_format) Previous discussions (>2y old): https://news.ycombinator.com/item?id=9943589 and https://news.ycombinator.com/item?id=10245737 A slideset: https://www.slideshare.net/insideHPC/unum-computing-an-energ.…

William Kahan, who's the person mainly responsible for IEEE 754, has a critique of Gustafson's proposal:

http://people.eecs.berkeley.edu/~wkahan/UnumSORN.pdf

IEEE 754 is not a trivial standard (it earned Kahan a Turing award). Error modes for IEEE 754 are precisely defined, even though it requires a lot of effort to understand what they mean. (For example, overflow triggers an exception, but gradual underflow is allowed.) Going beyond it requires some serious effort, and unums seem not to be the solution.

A good book to understand the IEEE 754 standard is the book by Michael Overton. The quoted article is unfortunately an example of floating-point "scaremongering". Floating point arithmetic is not approximate, it is accurately defined with precise error modes. Base-10 arithmetic is not however, the model to understand it, but rather "units in last place".

Re: 0.30000000000000004

#98
post #42

Earlier quoted context omitted.

Python does this, for example (but likely in a more efficient way): http://bugs.python.org/issue1580 See also http://www.netlib.org/fp/ http://web.archive.org/web/20060908072403/http://ftp.ccs.neu... So for instance 0.29999999999999993 + 0.00000000000000003 -> 0.3, but 0.30000000000000002 -> 0.30000000000000004 Note that this will still not solve the 0.1 + 0.2 problem from the OP, since the nearest float to 0.3 is no…

> Note that this will still not solve the 0.1 + 0.2 problem from the OP, since the nearest float to 0.3 is not actually the same as the nearest float to 0.1 + 0.2. Interval arithmetic can be used, although that requires double the storage for all the intermediate results, and extra work. For example, .1 can be represented by x=[x0, x1], where x0 and x1 are floating point values bracketing .1, and similarly .2 can be…

Interval arithmetic is far from trivial. 1/(1/x+1/y) is not the same as xy/(x+y). It breaks things more than normal floating point math does.

Re: 0.30000000000000004

#99
How does Postgres "work" properly? I was wondering this the other day. Is something magical going on behind the scenes that I should know about? I added a ::decimal to be safe, but I wasn't sure

Re: 0.30000000000000004

#100

It's stuff that should be a part of very beginning of any CS101. Float arithmetics != Decimal arithmetics

Only if you're trying to scare the newbies away. This stuff does need to be learned at some point but cs101 should be about getting a feel for programming in general. Focusing on the basics of objects/classes functions (with mandatory source control) is smart before killing their will to learn with nasty edge cases

I don't think fumbling around in a trial and error manner is the best start. The basic data types and the set of values they can represent should come early.
Post reply on HN