Comments on: Day 14: Going to the Rats

By: colomon

colomon — Tue, 15 Dec 2009 16:33:13 +0000

In the spec, Rats are Int over uint64 (that is, a unlimited size big num integer over an unsigned 64-bit int), so these issues do apply. If you need unlimited precision regardless of efficiency, the spec provides the FatRat type, which is an Int over an another Int. There’s been no attempt to implement this, as Rakudo does not have bignums yet.

By: Roie

Roie — Tue, 15 Dec 2009 15:57:18 +0000

Given that automatic bignums are in the spec, shouldn’t the 1/60000+1/60001 example always work, even for huge numbers? I.e., shouldn’t (1/$x+1/$y).WHAT always be Rat, regardless of the size of $x and $y?

By: Moritz

Moritz — Mon, 14 Dec 2009 19:33:09 +0000

In fact I had a use case right away when they were implemented: In a chart plotting library floating point errors would mean that the Zero-tick would actually be 1e-17 or so.

Instead of special-casing the zero, I changed a few lines in my code and had rats working, and “magically” the 1e-17 became 0.

See here for an illustration: http://perlgeek.de/blog-en/perl-6/rats-and-other-pets.html

By: Ricardo Signes

Ricardo Signes — Mon, 14 Dec 2009 19:25:34 +0000

That was great — probably one of the most fun (for me) articles so far. I have no darn idea what I’d ever use them for, but the overall interface and simplicity of use seems, from this post, really nice.

By: colomon

colomon — Mon, 14 Dec 2009 18:15:41 +0000

They are in the spec, but probably won’t make it into Rakudo until the second half of 2010.

By: bened

bened — Mon, 14 Dec 2009 16:43:10 +0000

Will there be automatic big numbers in Rakudo in future releases? That’s a feature I was always impressed by in Common Lisp.

By: colomon

colomon — Mon, 14 Dec 2009 07:11:06 +0000

It’s kind of wonky, which is why I think I skirted around the answer. Most directly, it’s because (in current Rakudo), 60000 * 60001 is a Num, not an Int, because it trips an Int overflow check after the multiplication. What’s weird about this is it trips that 32-bit overflow flag even if Rakudo is compiled with 64-bit Ints and thus is perfectly capable of storing 60000 * 60001 in an Int. (On my 32-bit OS X, (60000 * 60001).Int == -2147483648; on my 64-bit Linux machine, (60000 * 60001).Int == 3600060000. On both of them (60000 * 60001).WHAT is Num.)

In theory, an Int should be a BigNum and able to handle 60000 * 60001 with ease, but that’s not the case in Rakudo. But then, in theory, the denominator of a Rat should be an Int64, a 64-bit Int, but Rakudo doesn’t have such a type yet. Once these types are in place, the gist of the example still is correct, but you’ll need larger numbers that 60001 to see the effect in practice.)

By: Joe Z

Joe Z — Mon, 14 Dec 2009 05:33:33 +0000

It wasn’t immediately clear to me why “1 / 60000 + 1 / 60001″ shouldn’t also be a rational. Is it that Rats are built on Ints, and 60000 * 60001 doesn’t fit in an Int? If so, then that makes sense. “Int” doesn’t appear anywhere in the post, though.