Hacker News Reader

Comment by al2o3cr | Hacker News Reader

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

View on HN

> 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) that stays precise if you really want, but the default give precise arithemtics for "usual" numbers without pathologic slow-down for pathologic cases.

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.

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.

I feel like this "do what I mean not what I say" is exactly what I have found so irksome about Perl

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

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

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.

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com