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

91–100 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#91

Post by zokier »

coddingtonbear wrote: post #70
Gibbon1 wrote: post #67

Earlier quoted context omitted.

> exceptionally good way to approximate You answered your question. 99% of the time being exact is a requirement and calculation speed is utterly unimportant, thus using IEEE 754 results in programs that are fundamentally broken.

Is that really true? In my experience, 99.9% of the time I don't need an exact number; the vanishingly few times when I have such a need (almost entirely calculations involving currency), using a fixed point representation is simple enough.

I think there is argument to be made for high-level languages defaulting for arbitrary precision math ("make it correct first, fast second"). But considering that we are still fumbling around with fixed-width integers and that is much simpler domain after all, I don't hold my breath on "solving" the problem of reals any time soon.

Re: 9999999999999999.0 – 9999999999999998.0

#92

Post by smallnamespace »

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.

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

Re: 9999999999999999.0 – 9999999999999998.0

#93

Post by dnautics »

ummonk wrote: post #85
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.

Well, you don't need to represent all the real numbers. You can get quite far with just rationals or algebraic numbers, although you'll have trouble with exponentials and trignometry. And computable numbers are basically superior to any other number system for computation. You of course need an unbounded but finite amount of space to store these numbers, which is perfectly fine.

> And computable numbers are basically superior to any other number system for computation.

I don't think that's really quite true. The point of FP is that you don't get any wierd statefulness in your compute complexity as values accumulate, every operation basically has O(1) compute time where N is the number of previous operations you've done. For rationals and algebraics that isn't the case.

Re: 9999999999999999.0 – 9999999999999998.0

#94

Post by chrisseaton »

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.

Right - if you have a monadic function that takes a 32-bit float, your tests should probably literally cover every single input value.

Re: 9999999999999999.0 – 9999999999999998.0

#95

Post by TazeTSchnitzel »

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.

Re: 9999999999999999.0 – 9999999999999998.0

#96

Post by saagarjha »

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...…

Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.

Re: 9999999999999999.0 – 9999999999999998.0

#97

Post by rurban »

mcguire wrote: post #58
jackfraser wrote: post #10

Earlier quoted context omitted.

You're probably being downvoted for posting like you're on some other site, moreso than your sentiment that this is just a simple CS 101 thing that people ought to know. Thing is, a lot of people don't take CS courses, and have to learn this as they go along. More importantly, the naive cases all seem to work fine - it's only when you get to increasing precision / scales that you notice the cracks in the facade, and…

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.

Re: 9999999999999999.0 – 9999999999999998.0

#98

Post by lizmat »

Aardwolf wrote: post #80

> Several of the results surprised me. Did they surprise you? Well, the perl6 result surprised me, since that means it's using something more precise than double precision floating point :)

They're called Rat (for Rational number): https://docs.perl6.org/type/Rat , which maintain precision until the denominator exceeds 64 bits: then they're downgraded to doubles. If you want to keep precision still at that level, you can use FatRat: https://docs.perl6.org/type/FatRat

Re: 9999999999999999.0 – 9999999999999998.0

#100

Post by empath75 »

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...…

You can work directly in reals.

http://hackage.haskell.org/package/exact-real

Post reply on HN