[OskarS]

I mean, yeah, if you force the numbers to be floats, then of course it's going to fail. I personally think Raku's way of defaulting to floats is the better way to go for a scripting language like this, and I disagree that "it fails for many other uses". It works just fine (like, it doesn't break if you pass it to sqrt() or whatever), it's just less performant. It's the exact same kind of tradeoff that Python's implicit promotion to big integers make.

[ChrisLomont]

>I disagree that "it fails for many other uses"

Having developed a significant amount of perfect precision math libs over the years, rationals do explode for lots of common computations. That is the main reason they are not standard in all computing. They also cannot represent a lot of desired results.

The problem is rational number performance slows exponentially (or uses large amounts of RAM) for many common uses, which will kill scripts, unless they suddenly fix precision (i.e., no longer exact) or change to float (also a surprise for people).

Setting them as floats has the odd numerical issue, which is not that bad, but doesn't require a host of other mitigations to prevent other bad surprises.

For example, summing 1/n^2 for n=1 to 100000 as floats runs quickly and is very close to the exact answer. As rationals the numerator and denominator require working with 86000 digit numbers.

Also, does raku still do this?

say (1/6+1/6).raku #<1/3>

say (1/10+1/10).raku #0.2

That seems surprising, does it not?

[p6steve]

Yes, that’s precisely what I am trying to say. With FatRat (aka BigInt) by default then the casual programmer has to know to step explicitly into Num (eg by 1e-1 + 2e-1 which needs a bit of a scientist mindset) or will never benefit from all those lovely FPU transistors.

[doc_holliwould]

say (1/10+1/10).WHAT; say (1/6+1/6).WHAT;

both are Rats, they just get stringified differently

[lizmat]

They stringify differently because 2/10 can be expressed exactly in NNN.MMM format, whereas 1/3 can not.