9999999999999999.0 – 9999999999999998.0 • Hacker News Board

Re: 9999999999999999.0 – 9999999999999998.0

#141

Post by sampo » Sun, Jan 06, 2019, 1:25 AM UTC

tasty_freeze wrote: post #126

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 I went to university in 1982, one of the lower level courses was called "Numerical Methods". It went over all of the issues related to precision, stability, as well as a host of common numerical integration and approximation methods. I'm just a sample size of one, but isn't this kind of class a requirement for CS majors?

> isn't this kind of class a requirement for CS majors?

I think most CS departments dropped numerical analysis from their requirements by the end of 1980s. Nowadays you are more likely to find such a course in some dusty corner of math or engineering departments.

Re: 9999999999999999.0 – 9999999999999998.0

#142

Post by sampo » Sun, Jan 06, 2019, 1:29 AM UTC

ori_b wrote: post #109

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.

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

I think the numbers would need to be something like

9999999999999995.0 – 9999999999999994.0 == 10.0000

Re: 9999999999999999.0 – 9999999999999998.0

#143

Post by int_19h » Sun, Jan 06, 2019, 1:30 AM UTC

smallnamespace wrote: post #105

ummonk wrote: post #101

Earlier quoted context omitted.

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.

A lot of real-world data is already in base-10 for obvious reasons, and so an arrangement that lets you add, subtract and multiply those without worrying is worthwhile, even if it can't handle something more exotic.

Re: 9999999999999999.0 – 9999999999999998.0

#144

Post by microcolonel » Sun, Jan 06, 2019, 1:32 AM UTC

delhanty wrote: post #134

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…

Exactly! Very far from a floating point expert here, but what I do is to scale-down by a few odd prime-power factors as appropriate: Scaling down by powers of 5 is obviously appropriate for decimals, currency etc. Scaling down by powers of 3 is good for angles measured in the degrees, minutes, seconds system. If one scales down a lot there is an increased risk of overflow, so one can compensate by scaling up some pow…

Integers are a lot less trouble for many currency problems, but I think some people are afraid of multiplying integer fractions.

In financial calculations I've seen, figures are given in standard magnitudes (per cent, per mille, basis points, integer cents, etc.) which, if you're lucky with your language, can be encoded as types which can be promoted to higher precision (somewhat) transparently.

Re: 9999999999999999.0 – 9999999999999998.0

#145

Post by tedunangst » Sun, Jan 06, 2019, 1:32 AM UTC

Gibbon1 wrote: post #74

coddingtonbear wrote: post #70

Earlier quoted context omitted.

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.

You don't need an exact number but customer data is universally decimal. Soon as you blindly convert that to IEE754 everything is now broken.

My 5/8s wrench disagrees. Happens to store quite nicely in a float, however.

Re: 9999999999999999.0 – 9999999999999998.0

#146

Post by sampo » Sun, Jan 06, 2019, 1:35 AM UTC

azhenley wrote: post #22

dsalaj wrote: post #14

Google calculator gives answer 0 where as duckduckgo calculator answers with 2. xD

Bing gives 1 though!

So duckduckgo uses the normal 64bit floating point, and the clever people at bing automatically switch to bignums when needed. But I have no idea what google does to get that 0?

Re: 9999999999999999.0 – 9999999999999998.0

#147

Post by int_19h » Sun, Jan 06, 2019, 1:37 AM UTC

spencerwgreene wrote: post #102

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.

The dangerous part is that now the value of the computation can change slightly if it's no longer constant. So e.g. if it involves a named constant, and that constant then becomes a variable for some reason (e.g. because it now needs to be computed at runtime, because it varies from platform to platform), you can end up with broken code with no warning.

Re: 9999999999999999.0 – 9999999999999998.0

#148

Post by azhenley » Sun, Jan 06, 2019, 1:43 AM UTC

sampo wrote: post #146

azhenley wrote: post #22

Earlier quoted context omitted.

Bing gives 1 though!

So duckduckgo uses the normal 64bit floating point, and the clever people at bing automatically switch to bignums when needed. But I have no idea what google does to get that 0?

I think Google is truncating the numbers. You get 0 even if you do:

9999999999999999 – 9999999999999990

Re: 9999999999999999.0 – 9999999999999998.0

#149

Post by loeg » Sun, Jan 06, 2019, 1:43 AM UTC

Well, duh. One of those numbers isn't accurately representable in IEEE 754 64-bit "double" values, which is likely what all of the failing languages use.

If you want more than 53 significant bits, you need something wider than a 64-bit IEEE double. And anyone who cares about such precision knows this and will expect to use a higher precision library. (Or is an incredibly specialized math language, like Wolfram.)

If you think having only 53 significant bits is bad, you should see how many bits common trigonometry operations lose in libm implementations.

Another fun example: video games (historically) have thrown away even 53 significant bits for the higher performing 32-bit floats.

Re: 9999999999999999.0 – 9999999999999998.0

#150

Post by leiroigh » Sun, Jan 06, 2019, 1:45 AM UTC

TFortunato wrote: post #121

garmaine wrote: post #117

Earlier quoted context omitted.

That hasn’t been the case for over a decade.

How do you mean? The x86-64 instruction set / abi specifies long doubles as 80-bits, and still supports them ...

And nobody uses this terrible mis-feature in practice, everything runs via 64 bit xmm registers.

Rightly so, because programmers want their optimizing compiler to decide when to put a variable on the stack and when to elide a store/load cycle by keeping it in a register. With 80 bit precision, this makes a semantic difference and you end up in volatile hell.