&gt; &quot;easily stored on a computer&quot; is too vague and reductive.<p>Fwiw, from the compiler source code:<p><pre><code>    my role Rational[::NuT, ::DeT] does Real {
        has NuT $.numerator;
        has DeT $.denominator;
</code></pre>
&gt; Your position seems to be that rational arithmetic is an obvious choice<p>Yes. Rational storage and rational arithmetic is an obvious choice for storing and processing rational numbers. (Alongside the other obvious choice -- using floats.)<p>&gt; other languages have been too lazy or stupid<p>I&#x27;m extolling what I consider a minor Perl 6 virtue. Where have I been negative toward other languages?<p>&gt; rational arithmetic is a fine choice for ...<p>... doing rational arithmetic.<p>&gt; it is not a strict improvement over other number representations.<p>For representing Integers? Sure. Irrationals? Agreed. Complex numbers? Gotchya. Number crunching where absolute exactness is not necessary? Use floats.<p>But if exactness is required and a formula only involves rational numbers (and integers) then rational storage and processing is a strict improvement over use of floats.<p>&gt; [rationals are] not as perfect, and floating point is not as bad, as you seem to think.<p>When did I suggest floats are bad? The general number type in Perl 6 is a float. Floats are awesome! But floats are <i>by design</i> not exact for arbitrary rational numbers. Their awesomeness derives directly from them being <i>inexact</i> in this way.<p>When did I suggest storing rationals is perfect? They use up more memory than floats and processing can become pathologically slow if the denominators get big enough. This problem derives directly from them being <i>exact</i>.<p>&gt; doubles have lots of values they can&#x27;t represent perfectly, but so do rationals. Like sqrt(2), sin(1), pi<p>Those are explicitly defined in mathematics as numbers that are not rational. Rational storage and arithmetic is for representing and processing numbers that are rational!<p>One can&#x27;t exactly store an irrational number. The Perl 6 compiler defines a constant for the irrational number `pi`:<p><pre><code>    my constant pi = 3.14159_26535_89793_238e0;
</code></pre>
The &#x27;e0&#x27; on the end means that `pi` is stored as a float.<p>&gt; Some slides I found about Perl 6 indicate that Rat values lose precision if the denominator gets too big, to avoid using too much memory.<p>The numerator of a default rational (a non-parameterized Rat) can be arbitrarily large but if the denominator exceeds 64 bits (20 decimal digits) then the compiler converts the number to a float.<p>If you don&#x27;t like that then you can use a rational with a larger denominator, with the extreme being a FatRat that has an arbitrary sized denominator as well as arbitrary sized numerator.<p>&gt; If this is true, the Rat type shouldn&#x27;t be thought of as an &quot;exact&quot; type any more than double<p>I think that view misses something very important. This is indeed where the discussion could get interesting. We shall see. It seems we needed to get past a lot of misunderstanding first.<p>&gt; What I&#x27;m disagreeing with overall is the dichotomy you are trying to create of: double=approximate, Perl 6 number=exact.<p>I&#x27;ve never said that. What I have said is that, for storing and processing <i>rational numbers</i>, doubles are approximate (and they are); that it&#x27;s possible to be exact instead (and it is); and that Perl 6 returns True for the expression `0.1 + 0.2 == 0.3` because by default it processes rationals as exact rationals.<p>&gt; There are cases where double is exact<p>Not for rational numbers (I&#x27;m ignoring silly examples like 1&#x2F;1 and others that happen to work out because the denominator and numerators are powers of two or whatever).<p>&gt; and cases where Perl 6 is not exact.<p>Not for rational numbers, if you choose to have them be exact.