Motzkin numbers: Difference between revisions
m
→native: use small font
m (→native: actually M[36] only by chance on 32bit too, and the intermediate M[37] is rounded to the nearest 4 not 16.) |
m (→native: use small font) |
||
Line 451:
</pre>
===native===
Normally I'd start with this simpler and perfectly valid 64-bit code, but at the moment am somewhat biased towards things that run online, without limiting things as this does.
Note that, under 32-bit and p2js, M[36] and M[37] happen only by chance to be correct: an intermediate value exceeds precision (in this case for M[36] it is a multiple of 2 and hence ok, for M[37] it is rounded to the nearest multiple of 4), and the final divide by (i+1) results in an integer simply because there isn't enough precision to hold any fractional part.▼
Output as above on 64-bit, less four entries under 32-bit and pwa/p2js, since unlike M[36..37], M[38..41] don't quite get away with the precision loss, plus M[39] and above exceed is_prime() limits on 32-bit anyway.▼
<!--<lang Phix>(phixonline)-->
<span style="color: #008080;">with</span> <span style="color: #008080;">javascript_semantics</span>
Line 473 ⟶ 471:
<span style="color: #008080;">end</span> <span style="color: #008080;">for</span>
<!--</lang>-->
▲Aside: <small>Note that, under 32-bit and p2js, M[36] and M[37] happen only by chance to be correct: an intermediate value exceeds precision (in this case for M[36] it is a multiple of 2 and hence ok, for M[37] it is rounded to the nearest multiple of 4
▲Output as above on 64-bit, less four entries under 32-bit and pwa/p2js, since unlike M[36..37], M[38..41] don't quite get away with the precision loss, plus M[39] and above exceed precision and hence is_prime() limits on 32-bit anyway.</small>
=={{header|Raku}}==
| |||