4 ms·

> For what its worth, perl6 passes this test with flying colours. Do we really expect calculations on floating point numbers to be the same as calcualtions wit

> For what its worth, perl6 passes this test with flying colours. Do we really expect calculations on floating point numbers to be the same as calcualtions with real numbers? The only problem I see is that often the floating point format is not specified properly. When one writes "0.3", what does it actually mean? Does the format the compiler uses internally conform to IEEE 754? Is it 32bit, 64bit, 80bit or something else?

Piskvorrr 11y ago
In other words, there are about 5648798746465 possible interpretations of the "(\+|-|)[0-9]+.[0-9]+" format, and the problem is with mismatched assumptions ("of course I'm using the One Correct Interpretation, like everyone else!").
panic 11y ago
The only problem I see is that often the floating point format is not specified properly. When one writes "0.3", what does it actually mean? It's perfectly well-specified. If you are using double-precision floating point, "0.3" means 0x3fd3333333333333 (as bits), or 0.299999999999999988897769753748434595763683319091796875 (as an exact number: the closest representable number to 0.3).
- static_noise 11y ago
  When your compiler does its internal calculations in double precision float you are right. But why should it do so? Do all languages specify the details of how floating point input is handled by the compiler/interpreter?
  - tinco 11y ago
    I think so, yes.
  - gsnedders 11y ago
    Most languages do (though implementation bugs are common—plenty of languages where 64-bit precision is required actually end up being implemented in such a way that 80-bit precision is used on x86). That said, a lot of low-level languages don't: C doesn't guarantee this, for example. C doesn't even mandate IEEE 754, and it merely requires that "float" is a subset of the values of "double" which is itself a subset of the values of "long double".
amyjess 11y ago
Perl 6 doesn't use IEEE 754 by default at all. It internally stores decimal literals as rational numbers, with numerator and denominator in separate fields, and it only resolves back to a decimal number when you convert it to a string.

Piskvorrr 11y ago

In other words, there are about 5648798746465 possible interpretations of the "(\+|-|)[0-9]+.[0-9]+" format, and the problem is with mismatched assumptions ("of course I'm using the One Correct Interpretation, like everyone else!").

panic 11y ago

The only problem I see is that often the floating point format is not specified properly. When one writes "0.3", what does it actually mean? It's perfectly well-specified. If you are using double-precision floating point, "0.3" means 0x3fd3333333333333 (as bits), or 0.299999999999999988897769753748434595763683319091796875 (as an exact number: the closest representable number to 0.3).

static_noise 11y ago
When your compiler does its internal calculations in double precision float you are right. But why should it do so? Do all languages specify the details of how floating point input is handled by the compiler/interpreter?
- tinco 11y ago
  I think so, yes.
- gsnedders 11y ago
  Most languages do (though implementation bugs are common—plenty of languages where 64-bit precision is required actually end up being implemented in such a way that 80-bit precision is used on x86). That said, a lot of low-level languages don't: C doesn't guarantee this, for example. C doesn't even mandate IEEE 754, and it merely requires that "float" is a subset of the values of "double" which is itself a subset of the values of "long double".

amyjess 11y ago

Perl 6 doesn't use IEEE 754 by default at all. It internally stores decimal literals as rational numbers, with numerator and denominator in separate fields, and it only resolves back to a decimal number when you convert it to a string.