4 ms·
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
by 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 agoThere 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.