9999999999999999.0 – 9999999999999998.0 • Hacker News Board

Whenever I see these examples I do get annoyed st the Haskell one because we never are told what type it gets defaulted to, which only happens silently in the ghci repl, but will trigger a warning if it’s in a source file that’s being compiled.

Re: 9999999999999999.0 – 9999999999999998.0

#7

Post by throwawaymath » Sat, Jan 05, 2019, 4:38 PM UTC

anothergoogler wrote: post #4

DAE mind blown by imprecision in float arith? Edit: Down-Voters go ahead and explain the LIE that is computer accuracy in the face of the linked demonstration. Computers, can't trust em.

I didn't downvote you, but this isn't a problem with computers. It's a problem with the (mis)use of floats.

Floats are not decimals. That's unfortunately a really, really common misconception, owing in part to poor education. Developers reach for floats to represent decimals without thinking about the precision ramifications.

When you're working with decimals that don't need a lot of precision this doesn't generally come up (and naturally, those are the numbers typically used in textbooks). But when you start doing floating point arithmetic with decimals that require significant precision, things get bizarre very fast.

Unfortunately if a developer isn't expecting it, that's likely to happen in production processing code at a very inopportune time. But the computer is just doing what it's told - we have the tools to support safe and precise arithmetic with decimals that need it. It's a matter of knowing how and when to use floating point.

Re: 9999999999999999.0 – 9999999999999998.0

#8

Post by misterdoubt » Sat, Jan 05, 2019, 4:38 PM UTC

Using one of these workarounds requires a certain prescience of the data domain

I'm a little concerned if merely knowing the existence of floating point arithmetic constitutes "prescience."

Re: 9999999999999999.0 – 9999999999999998.0

#9

Post by sp332 » Sat, Jan 05, 2019, 4:38 PM UTC

gpm wrote: post #3

2 with 64 bit floats, 0 with 32 bit floats.

I could understand 0, but how does it get 2?

Re: 9999999999999999.0 – 9999999999999998.0

#10

Post by jackfraser » Sat, Jan 05, 2019, 4:39 PM UTC

anothergoogler wrote: post #4

DAE mind blown by imprecision in float arith? Edit: Down-Voters go ahead and explain the LIE that is computer accuracy in the face of the linked demonstration. Computers, can't trust em.

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 that's only if you have something that depends on the real accuracy (e.g. real world consequences from being wrong) or if someone bothers to go and check (using some other calculator that gives more precise results).

My own view on it is that it's past bloody time for languages to offer a fully abstracted class of real numbers with correct, arbitrary precision math - obviating the need for the developer to specify integer, float, long, etc. I don't mean that every language should act like this, but ones aimed at business software development, for example, would do well to provide a first-class primary number type that simply covers all of this properly.

Yes, I can understand that the performance will not be ideal in all cases, but the tradeoff in terms of accuracy, starting productivity, and avoiding common problems would probably be worth it for a pretty big subset of working developers.