Talk:Legendre prime counting function: Difference between revisions
Talk:Legendre prime counting function (view source)
Revision as of 22:22, 10 November 2022
, 1 year agoV and C examples giving the wrong answer for a trillion numbers.
No edit summary |
(V and C examples giving the wrong answer for a trillion numbers.) |
||
Line 17:
Thanks for clarifying, and thanks for the update to the description, this makes it a lot more clear. Updated my Mathematica solution to have pi(1) = 0.
== V and C entries giving the wrong answer for a trillion numbers ==
The V entry gives a count of 35,460,428,370 primes as does the C entry (which I've translated from V).
However, according to [https://primes.utm.edu/howmany.html this independent source], the correct answer is 37,607,912,018.
Curiously, the Go and Wren entries which I've also translated from V give the correct answer for a trillion numbers and the Go entry carries on giving the correct answers up to 10^15 numbers (Wren up to 10^13 - I didn't bother after that). However, both V and C produce a segmentation fault when I try 10^13.
It eventually dawned on me that the reason for this is that the 'int' type in V and also C (at least in GCC) is 4 bytes, whereas in Go (and I think Nim) it's 8 bytes on a 64-bit system. Wren effectively has 53 bit integers.
Consequently, this line in the V example is producing an overflow:
<pre>
mut ans := larges[0] + i64(((rilmt + 2 * (nbps - 1)) * (rilmt - 1) / 2))
</pre>
If we change it to:
<pre>
mut ans := larges[0] + i64(rilmt + 2 * (nbps - 1)) * i64(rilmt - 1) / 2
</pre>
then the correct number of primes is returned for a trillion numbers.
There's still a segmentation fault when I try to go above a trillion which I haven't been able to track down though, as the Go example is working, probably the easiest way to fix this is to change 'int' to 'int64' throughout. --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 22:21, 10 November 2022 (UTC)
| |||