5 ms·

Rational-as-default seems like an odd choice. It prevents catastrophic cancellation (the ".1 + .2 - .3" from the article is an example) but at the cost of patho

by al2o3cr 12y ago

Rational-as-default seems like an odd choice. It prevents catastrophic cancellation (the ".1 + .2 - .3" from the article is an example) but at the cost of pathological complexity for some operands. For instance, summing the harmonic series (nth term is 1/n) means doing massive amounts of factoring to keep intermediate results in lowest terms...

jzwinck 12y ago
How many programs written in Perl do you think add currency values together, vs. how many sum the harmonic series?
- reikonomusha 12y ago
  Consider computing compound interest using rationals. That's a practical thing that could happen akin to harmonic series calculation, where you'll get absurdly large rationals.
  - smosher_ 12y ago
    Considering .exp results in a Num, not a Rat, there's no problem here. I seem to recall this working sensibly years ago, where numerical types would coerce in sensible manner. Same happens with large denominators, so even if you roll your own successive approximation it will coerce away from Rat before things get out of hand.
nemo1618 12y ago
That was my first reaction too, but I think we're reaching the point where the increased computational complexity is manageable. Efficiency has certainly never been one of Perl's selling points. I imagine there's a trapdoor available if you want to use floats anyway; actually, knowing Perl, I'm sure of it.
- colomon 12y ago
  There are (at least) two trapdoors. The first is that an operation on Rats which would produce a denominator which does not fit in a 64-bit unsigned integer will produce a Num instead. (If you're okay with your denominators growing in an unbounded fashion, you can use the FatRat class instead.) The second "trapdoor" is that you can just explicitly work with Nums (ie C doubles). If your numeric literal has a exponent (eg 1e-15), it's automatically a Num. Or you can convert any Real numeric type to a Num by calling the .Num method on it.
- perlgeek 12y ago
  > Efficiency has certainly never been one of Perl's selling points. It has been, in fact. It's been faster than Python and Ruby for a very long time (though that's changing now with some new implementations like pypy). > I imagine there's a trapdoor available if you want to use floats anyway; actually, knowing Perl, I'm sure of it. Yes, if you use scientific notation (1e-1 etc.) you get floating points.
deleted 12y ago
[deleted]
conistonwater 12y ago
You don't need factoring to add rational numbers and reduce fractions, only greatest common divisor.
- Sniffnoy 12y ago
  And -- to be totally explicit -- although the naïve way of finding GCD is based on factoring, in fact finding GCD can be done very quickly with Euclid's algorithm, without any need for factoring.
perlgeek 12y ago
> For instance, summing the harmonic series (nth term is 1/n) means doing massive amounts of factoring to keep intermediate results in lowest terms... There is a feature in Perl 6 that the OP didn't mention: if the denominator doesn't fit into a 64 bit integer anymore, it falls back to floating point arithmetic. There's a type (FatRat, http://doc.perl6.org/type/FatRat http://doc.perl6.org/type/FatRat) that stays precise if you really want, but the default give precise arithemtics for "usual" numbers without pathologic slow-down for pathologic cases.
- xioxox 12y ago
  Is this kind of mixed rational/floating point sensible? It seems to be a fuzzy do-what-I-mean, not what-I-say kind of arithmetic. Surely weird differences in algorithm behaviour might occur around the 64 bit integer limit. It will also make the analysis and testing of numerical algorithm accuracy very difficult unless you can put bounds on your input values.
  - kbenson 12y ago
    I think the point is that it does what what you mean in the majority of cases. If you know you are going to need specific functionality such as floats or large rationals, specify the type of your variables up front. This is an are where the optional type system can help.
  - leoh 12y ago
    I feel like this "do what I mean not what I say" is exactly what I have found so irksome about Perl
- omaranto 12y ago
  I like that the first thing the documentation says is that "class FatRat is Cool". :) Being cool seems to mean having automatic conversion to and from strings: http://doc.perl6.org/type/Cool http://doc.perl6.org/type/Cool

by al2o3cr 12y ago

jzwinck 12y ago

How many programs written in Perl do you think add currency values together, vs. how many sum the harmonic series?

reikonomusha 12y ago
Consider computing compound interest using rationals. That's a practical thing that could happen akin to harmonic series calculation, where you'll get absurdly large rationals.
- smosher_ 12y ago
  Considering .exp results in a Num, not a Rat, there's no problem here. I seem to recall this working sensibly years ago, where numerical types would coerce in sensible manner. Same happens with large denominators, so even if you roll your own successive approximation it will coerce away from Rat before things get out of hand.

nemo1618 12y ago

That was my first reaction too, but I think we're reaching the point where the increased computational complexity is manageable. Efficiency has certainly never been one of Perl's selling points. I imagine there's a trapdoor available if you want to use floats anyway; actually, knowing Perl, I'm sure of it.

colomon 12y ago
There are (at least) two trapdoors. The first is that an operation on Rats which would produce a denominator which does not fit in a 64-bit unsigned integer will produce a Num instead. (If you're okay with your denominators growing in an unbounded fashion, you can use the FatRat class instead.) The second "trapdoor" is that you can just explicitly work with Nums (ie C doubles). If your numeric literal has a exponent (eg 1e-15), it's automatically a Num. Or you can convert any Real numeric type to a Num by calling the .Num method on it.
perlgeek 12y ago
> Efficiency has certainly never been one of Perl's selling points. It has been, in fact. It's been faster than Python and Ruby for a very long time (though that's changing now with some new implementations like pypy). > I imagine there's a trapdoor available if you want to use floats anyway; actually, knowing Perl, I'm sure of it. Yes, if you use scientific notation (1e-1 etc.) you get floating points.

deleted 12y ago

[deleted]

conistonwater 12y ago

You don't need factoring to add rational numbers and reduce fractions, only greatest common divisor.

Sniffnoy 12y ago
And -- to be totally explicit -- although the naïve way of finding GCD is based on factoring, in fact finding GCD can be done very quickly with Euclid's algorithm, without any need for factoring.

perlgeek 12y ago

> For instance, summing the harmonic series (nth term is 1/n) means doing massive amounts of factoring to keep intermediate results in lowest terms... There is a feature in Perl 6 that the OP didn't mention: if the denominator doesn't fit into a 64 bit integer anymore, it falls back to floating point arithmetic. There's a type (FatRat, http://doc.perl6.org/type/FatRat http://doc.perl6.org/type/FatRat) that stays precise if you really want, but the default give precise arithemtics for "usual" numbers without pathologic slow-down for pathologic cases.

xioxox 12y ago
Is this kind of mixed rational/floating point sensible? It seems to be a fuzzy do-what-I-mean, not what-I-say kind of arithmetic. Surely weird differences in algorithm behaviour might occur around the 64 bit integer limit. It will also make the analysis and testing of numerical algorithm accuracy very difficult unless you can put bounds on your input values.
- kbenson 12y ago
  I think the point is that it does what what you mean in the majority of cases. If you know you are going to need specific functionality such as floats or large rationals, specify the type of your variables up front. This is an are where the optional type system can help.
- leoh 12y ago
  I feel like this "do what I mean not what I say" is exactly what I have found so irksome about Perl
omaranto 12y ago
I like that the first thing the documentation says is that "class FatRat is Cool". :) Being cool seems to mean having automatic conversion to and from strings: http://doc.perl6.org/type/Cool http://doc.perl6.org/type/Cool