Hacker News Reader

Comment by conistonwater | Hacker News Reader

Quote from the paper:

> To avoid the usual problems with floating point arithmetic (rounding, truncating, instability), we construct all our examples with integers.

I think this is complete overkill. I know floating-point arithmetic can be tricky, but it's not at all random. If you have a stable algorithm and a multiple precision floating-point library, you can use floating point numbers. It won't necessarily give you a proof that your result (unless you spend time to derive rigorous error bounds), but it will certainly be good enough.

I think people sometimes do slightly irrational things for fear of floating-point arithmetic.

View on HN

As someone who has done lots of work with floating point, I disagree. My fear (or more properly caution) with floating point includes tricks like if you are going to add up an array of floating point numbers, you need to sort them first. The experienced floating-point programmer will know what order you need to do this in.

The inability to represent 0.1 properly in binary floating point is not a problem solved by increasing the precision your floating point library.

Also, there can be be surprising cases where single-precision might not be enough. For example, if you are going to represent exchange prices for, say, futures, you need to take into account that some of the price increments are in pennies, some in fractional dollars. You need the calculations to be reversible, and to have enough precision and accuracy to represent the whole range of price increments and expected volume.

One example of a lack of appropriate paranoia about floating point numbers was the i'm-not-very-good-at-writing-parsers' author of ASP and the result was http://www.exploringbinary.com/php-hangs-on-numeric-value-2-... denial of service to all unpatched PHP sites. Also bit java.

Note that interesting prime number work depends on integers and won't work with floating point. Including factoring large numbers in cryptography.

In the context of this paper, we are talking about floating point arithmetic used by mathematicians working in Mathematica. I disagree with you on these points.

> you need to sort them first

Yes, but only if there are quite a lot of them and the partial sums are large relative to the result. Not really an issue usually.

> The inability to represent 0.1

Many mathematical conjectures apply for arbitrary real numbers. The nearest floating point number to 0.1 is a real number, and it's not really an issue for mathematics that it's not exactly 0.1.

> single-precision might not be enough

These are mathematicians working in Mathematica, which has an arbitrary-precision floating-point type. They don't have to come anywhere near single precision floats.

> if you are going to represent exchange prices

You can use integers. Floating-point arithmetic isn't really great here because it makes the wrong kinds of accuracy guarantees.

> prime number work

Primes numbers are all integers. It would be a bit silly to represent integers with floating-point numbers.

>tricks like if you are going to add up an array of floating point numbers, you need to sort them first.

...I think you'll want to use a priority queue, with the smallest numbers on top, adding the first two, and then pushing the result back onto the priority queue. Repeat until you only have one item left.

The number of people who add up arrays of floating point numbers and don't know about Kahan summation is really incredible.

It depends on what you are trying to accomplish. Multiple precision integers are not necessarily slower than multiple precision floating point numbers. And if you're doing pure math research, chances are that you do care about results being provably correct, in which case the much simpler semantics of integers is a great advantage.

Yes, you're definitely right.

They were computing determinants of matrices. Try doing that on your fancy-schmancy double float matrix in MATLAB.

If using integers doesn't do a disservice to their findings, it makes complete sense to avoid the can of worms that is floating-point arithmetic.

Similarly, if I need to write an app that deals with real money (say, a banking application), you can bet your bottom dollar I'll be using integer arithmetic.

> It won't necessarily give you a proof that your result...

That is precisely the point.

The numbers they were working with were way out past the bounds of doubles, and a significant fraction of the way to the largest quadruple precision number (second column, bottom of page 1250).

Libraries, such as mpfr, that implement multiple-precision floating-point arithmetic are completely standard. At best maybe you can argue that it introduces extra programming work over regular doubles, but in Mathematica it is no work at all as it has an arbitrary-precision floating-point type.

Reply on news.ycombinator.com