5 ms·

As a mathematician, I am actually very surprised by perl's 6 behavior here. What the hell is going on? Does it use fixed point arithmetic or what?

SamReidHughes 7y ago
They have this totally irrational idea of having "rational" numbers. https://docs.perl6.org/language/numerics#Rational https://docs.perl6.org/language/numerics#Rational By irrational I am not joking, these sorts of number systems are complicated and glitchy, in this case with program-destroying magic like autoconversion to floating point when you hit a 2^64 denominator, and, don't click this URL, please, just read it: https://docs.perl6.org/language/numerics#Zero-denominator_rationals https://docs.perl6.org/language/numerics#Zero-denominator_ra...
- lizmat 7y ago
  > totally irrational idea Could you expand on why it is a totally irrational idea? Seems pretty rational to me. But then I'm not really a mathematician. > autoconversion to floating point when you hit a 2^64 denominator Please note that this is after normalization. And it has come from practicality: having the denominator also be an BigInt, slows down the use of the Rational number significantly. However, if you do need that type of precision, then you can by using infectious FatRats: any expression with a FatRat, will result in a FatRat (unless explicitly coerced to something else, of course). With regards to the Zero-denominator Rats: they are just special cases just as IEEE has special cases for -Inf, Inf and NaN. So what's the problem there?
  - SamReidHughes 7y ago
    It adds gratuitous corner cases to the language.
lizmat 7y ago
FWIW, Perl 6 prefers to be called Raku now.
dragonwriter 7y ago
It uses exact rational arithmetic for values that it can represent that way, preferring correctness to efficiency. Scheme and some other languages do the same thing. Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing.
- enriquto 7y ago
  > It uses exact rational arithmetic for values that it can represent that way, preferring correctness to efficiency. This is exactly the same situation as with floating point numbers. In both cases you have a predetermined finite set of rational numbers, with exact rational arithmetic when you stay within those numbers, and deterministic rules when your operation exits this finite set. > Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing. I do not see how this is a matter of precision nor efficiency. Floating point arithmetic was deemed more useful for general purpose for good reasons: the representable numbers are mostly scale-free, so that you do not care about the absolute size of your numbers (you can compute in armstrongs or in parsecs and obtain essentially the same results). With rational arithmetic using bounded integers, you cannot represent very large or very small numbers. On the other hand you can represent small fractions like 1/3, which is arguably useful in some cases, but not really a big deal in practice. There's no reason why rational arithmetic with bounded numerator and denominator could not be efficiently implemented in hardware as fast as floating point; I do not understand your point.
  - saithound 7y ago
    It is not at all the same situation as with floating point numbers. 1. It does not use a predetermined finite set of rational numbers. It uses a bigint numerator and a 64-bit denominator. 2. Even the case of bounded numerator and bounded denominator would preserve more of the nice mathematical properties of rational arithmetic than IEEE 754 floating-point arithmetic does (e.g. the associativity of addition). 3. While the latter could be implemented in hardware, it is not implemented in hardware. The defaults for literals prefer the choice that is implemented in hardware, IEEE 754 floating-point. This is a premature optimization.

SamReidHughes 7y ago

They have this totally irrational idea of having "rational" numbers. https://docs.perl6.org/language/numerics#Rational https://docs.perl6.org/language/numerics#Rational By irrational I am not joking, these sorts of number systems are complicated and glitchy, in this case with program-destroying magic like autoconversion to floating point when you hit a 2^64 denominator, and, don't click this URL, please, just read it: https://docs.perl6.org/language/numerics#Zero-denominator_rationals https://docs.perl6.org/language/numerics#Zero-denominator_ra...

lizmat 7y ago
> totally irrational idea Could you expand on why it is a totally irrational idea? Seems pretty rational to me. But then I'm not really a mathematician. > autoconversion to floating point when you hit a 2^64 denominator Please note that this is after normalization. And it has come from practicality: having the denominator also be an BigInt, slows down the use of the Rational number significantly. However, if you do need that type of precision, then you can by using infectious FatRats: any expression with a FatRat, will result in a FatRat (unless explicitly coerced to something else, of course). With regards to the Zero-denominator Rats: they are just special cases just as IEEE has special cases for -Inf, Inf and NaN. So what's the problem there?
- SamReidHughes 7y ago
  It adds gratuitous corner cases to the language.

lizmat 7y ago

FWIW, Perl 6 prefers to be called Raku now.

dragonwriter 7y ago

It uses exact rational arithmetic for values that it can represent that way, preferring correctness to efficiency. Scheme and some other languages do the same thing. Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing.

enriquto 7y ago
> It uses exact rational arithmetic for values that it can represent that way, preferring correctness to efficiency. This is exactly the same situation as with floating point numbers. In both cases you have a predetermined finite set of rational numbers, with exact rational arithmetic when you stay within those numbers, and deterministic rules when your operation exits this finite set. > Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing. I do not see how this is a matter of precision nor efficiency. Floating point arithmetic was deemed more useful for general purpose for good reasons: the representable numbers are mostly scale-free, so that you do not care about the absolute size of your numbers (you can compute in armstrongs or in parsecs and obtain essentially the same results). With rational arithmetic using bounded integers, you cannot represent very large or very small numbers. On the other hand you can represent small fractions like 1/3, which is arguably useful in some cases, but not really a big deal in practice. There's no reason why rational arithmetic with bounded numerator and denominator could not be efficiently implemented in hardware as fast as floating point; I do not understand your point.
- saithound 7y ago
  It is not at all the same situation as with floating point numbers. 1. It does not use a predetermined finite set of rational numbers. It uses a bigint numerator and a 64-bit denominator. 2. Even the case of bounded numerator and bounded denominator would preserve more of the nice mathematical properties of rational arithmetic than IEEE 754 floating-point arithmetic does (e.g. the associativity of addition). 3. While the latter could be implemented in hardware, it is not implemented in hardware. The defaults for literals prefer the choice that is implemented in hardware, IEEE 754 floating-point. This is a premature optimization.