5 ms·

Quote from the paper: > To avoid the usual problems with floating point arithmetic (rounding, truncating, instability), we construct all our examples with inte

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.

dvt 12y ago
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.
GFK_of_xmaspast 12y ago
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).
- conistonwater 12y ago
  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.
fdej 12y ago
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.
- conistonwater 12y ago
  Yes, you're definitely right.
wglb 12y ago
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-2250738585072011e-308/ 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.
- conistonwater 12y ago
  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.
- GregBuchholz 12y ago
asuidyasiud 12y ago
> It won't necessarily give you a proof that your result... That is precisely the point.
enupten 12y ago
They were computing determinants of matrices. Try doing that on your fancy-schmancy double float matrix in MATLAB.

dvt 12y ago

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.

GFK_of_xmaspast 12y ago

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

conistonwater 12y ago
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.

fdej 12y ago

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.

conistonwater 12y ago
Yes, you're definitely right.

wglb 12y ago

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-2250738585072011e-308/ 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.

conistonwater 12y ago
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.
GregBuchholz 12y ago

asuidyasiud 12y ago

> It won't necessarily give you a proof that your result... That is precisely the point.

enupten 12y ago

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