Smarandache prime-digital sequence: Difference between revisions
m
→{{header|Phix}}: added largest <10,000,000 etc
m (Typo fix) |
m (→{{header|Phix}}: added largest <10,000,000 etc) |
||
Line 1,179:
populate_spds(p)
printf(1,"spds[%d]:%d\n",{p,spds[p]})
end for
for n=7 to 10 do
atom p = power(10,n),
dx = abs(binary_search(p,spds))-1
printf(1,"largest spds prime less than %,15d:%,14d\n",{p,spds[dx]})
end for
?elapsed(time()-t0)</lang>
Line 1,184 ⟶ 1,189:
<pre>
spds[1..25]:{2,3,5,7,23,37,53,73,223,227,233,257,277,337,353,373,523,557,577,727,733,757,773,2237,2273}
spds[100]:
spds[
spds[
spds[
largest spds prime less than 10,000,000: 7,777,753
largest spds prime less than 100,000,000: 77,777,377
largest spds prime less than 1,000,000,000: 777,777,773
largest spds prime less than 10,000,000,000: 7,777,777,577
"3.6s"
</pre>
Line 1,194 ⟶ 1,203:
Go took 1 min 50 secs to calculate the 100,000th number - the optimised version got that down to 5.6s<br>
Julia crashed when the limit was changed to 100,000, however it took 11s just to calculate the 10,000th number anyway.<br>
The original Raku version was by far the slowest of all I tried, taking 1 min 15s just to calculate the 10,000th number, however it has since been replaced (I cannot actually run the latest Raku version, but I assume it is similar to the Perl one) and that completes near-instantly. Adding two 0 to limit in the C entry above gets a matching 777777773 on tio/clang in 27s, not directly comparable, and obviously you cannot add a 4th without changing those uint32.
=={{header|Python}}==
| |||