Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

Post reply on HN
Print view View original

101–110 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#101

Post by ummonk »

smallnamespace wrote: post #92
ummonk wrote: post #87

Earlier quoted context omitted.

Presumably we could actually make decimal floating point computation the default and greatly reduce the amount of surprise. I don't think the performance difference would be an issue for most software.

Decimal floating point won't avoid this issue, for a sufficiently large value the ulp would be 10.

It would solve more common issues like this though:

> I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem."

That's not a calculation that should require a high level of precision.

Re: 9999999999999999.0 – 9999999999999998.0

#102

Post by spencerwgreene »

The author says, "That Go uses arbitrary-precision for constant expressions seems dangerous to me."

Why?

My thoughts: 1) more inefficient programs because encountering an arbitrary-precision expression requires arbitrarily large memory and computation, 2) more complicated language implementation.

Re: 9999999999999999.0 – 9999999999999998.0

#103

Post by sampo »

svat wrote: post #71
twtw wrote: post #39

I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…

> considering the problem is to fit the reals into 64/32/16 bits and have fast math Floating-point numbers (and IEEE-754 in particular) are a good solution to this problem, but is it the right problem? I think the "minimum of surprises" part isn't true. Many programmers develop incorrect mental models when starting to program, and get no feedback to correct them until much later (when they get surprised). It is true…

There is a proposal about "unum" or "posit" number system. They give more precision for small numbers (small meaning smaller than about 10^70, for 64bit numbers), less precision for huge numbers, and an overall larger range, than the floating point system.

https://en.wikipedia.org/wiki/Unum_(number_format)

http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf

(They are definitely not any easier to understand than the floating point system, though.)

Re: 9999999999999999.0 – 9999999999999998.0

#104

Post by erik_seaberg »

lenticular wrote: post #52
twtw wrote: post #39

I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…

Yeah, the limitations of FP are well-known to anyone who does much numerical work. Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery's prior distribution. A Jeffery's prior is a prior that is invariant under reparameterization, which is a mandatory property for approximating the reals. In this case, it is where Prob(log(|x|)) is proportional to a const…

There's no reason for every step of a computation to be confined to the same very small message length. And the necessary error analysis should be built into the language, preferably in the same "advanced users only, here be dragons" package as the imprecise types themselves.

Re: 9999999999999999.0 – 9999999999999998.0

#105

Post by smallnamespace »

ummonk wrote: post #101
smallnamespace wrote: post #92

Earlier quoted context omitted.

Decimal floating point won't avoid this issue, for a sufficiently large value the ulp would be 10.

It would solve more common issues like this though: > I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." That's not a calculation that should require a high level of precision.

The correct solution is to understand how floating point number systems work and use near comparisons for floats.

Decimal fp is still 'wrong' for, say, 1/3 + 1/3 = 2/3.

Re: 9999999999999999.0 – 9999999999999998.0

#106

Post by trishmapow2 »

crankylinuxuser wrote: post #86
svat wrote: post #71

Earlier quoted context omitted.

> considering the problem is to fit the reals into 64/32/16 bits and have fast math Floating-point numbers (and IEEE-754 in particular) are a good solution to this problem, but is it the right problem? I think the "minimum of surprises" part isn't true. Many programmers develop incorrect mental models when starting to program, and get no feedback to correct them until much later (when they get surprised). It is true…

When NASA can't even get it right, because of "surprises", there's no chance in hell I'm blaming us mere mortal programmers... or even 10x wizards. (0) It's time to look at other ways to depict fractional parts of numbers in a computer. I know that one can express any rational number as a integer fraction. And our computers are incapable of expressing a irrational number exactly - it does so to a certain precision...…

Ariane 5 is ESA not NASA

Re: 9999999999999999.0 – 9999999999999998.0

#107

Post by jancsika »

m0zg wrote: post #84
chrisseaton wrote: post #56

Earlier quoted context omitted.

People get upset that floating point can’t represent all infinite number of real numbers exactly - I can’t understand how they think that’s going to be possible in a finite 64 bits.

To hit the point home a little harder: you can easily iterate through the entire representable set of float32 on a modern machine within seconds. I've encountered many engineers who don't quite get that.

Wait, where did OP's 64-bit slot go?

> I can’t understand how they think that’s going to be possible in a finite 64 bits.

You apparently stole 32 of them to make your bat.

If you put them back your tests balloon to half a century each.

Re: 9999999999999999.0 – 9999999999999998.0

#108

Post by chowells »

TazeTSchnitzel wrote: post #95
crankylinuxuser wrote: post #82

So.. Can someone better versed in the ways of system level programming tell me why we still use IEEE 754 exponential notation? Iv'e seen article after article of how "horrible it is". So, are there default libs to use Binary Coded Decimal (BCD) or something like that?

We use it because it's fast, accurate and very useful for many applications. It's not horrible.

In fact, as discussed in another thread, it's the optimal representation for many purposes. The only problems are that some languages over-privilege them to the point where it's difficult to use alternatives, and some programmers don't understand them.

Re: 9999999999999999.0 – 9999999999999998.0

#109

Post by ori_b »

ummonk wrote: post #87
twtw wrote: post #39

I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…

Presumably we could actually make decimal floating point computation the default and greatly reduce the amount of surprise. I don't think the performance difference would be an issue for most software.

Would ` 9999999999999999.0 – 9999999999999998.0 == 10.0000` really be less surprising?

Re: 9999999999999999.0 – 9999999999999998.0

#110

Post by chowells »

rurban wrote: post #97
mcguire wrote: post #58

Earlier quoted context omitted.

Exact real arithmetic is an open research problem (and slow, as well). Arbitrary precision has its own can of worms and is slow, too.

Not really. It's used for over 30 years successfully in all lisps. gmp is not really slow, and for limited precision (2k) there exist even faster libs.

gmp is not exact. It's just arbitrary-precision. There's a very large difference. Exact arithmetic handles numbers like pi with infinite precision. When you use gmp, you pre-select select a constant for pi with a precision known ahead of time. In the real world, 64 bits of pi is more than enough for almost every purpose, so whatever. It's fine. But there's a huge conceptual gap between that and exact arithmetic.
Post reply on HN