Talk:Extensible prime generator: Difference between revisions
→Bug in Fortran code: new section
(→Ada: Sorry.) |
(→Bug in Fortran code: new section) |
||
| (9 intermediate revisions by 6 users not shown) | |||
Line 3:
:Sorry. I see someone has removed the incorrect flag I put on Ada by mistake. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 19:49, 16 April 2014 (UTC)
== Off by one? ==
Rust and Seed7 disagree with the others regarding the 10.000th prime.--[[User:Steenslag|Steenslag]] ([[User talk:Steenslag|talk]]) 17:31, 5 January 2019 (UTC)
:According to published tables, the 10,000th prime is 104,729 so the 'other' languages are correct here.--[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 22.35, 6 January 2019 (UTC)
:: See the webpage <u>[https://primes.utm.edu/lists/small/10000.txt primes.utm.edu/small/10000.txt]</u> (at the very bottom). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:55, 6 January 2019 (UTC)
::: That just confirms that the correct value is 104,729. The Rust code was wrong; the author forgot that enumerations are zero based in Rust, so one has to ask for item number 9,999 to get the 10,000th prime. I've corrected Rust.
::: It appears that Seed had a slightly different logic error: it iterated and discarded the primes until the 10,000th one, then printed the next one. I've fixed that, too.--[[User:GordonBGood|GordonBGood]] ([[User talk:GordonBGood|talk]]) 23:25, 6 January 2019 (UTC)
== analytic formula for primes ==
Haskell's analytic formula for primes seems to essentially be a mechanism for packing the sequence of prime numbers into a number.
The expression is basically int(A*frac(B*C)) where values of A come from the sequence (6, 20, 42, 72, 110, 156, 210, 272, 342, 420, ...) and values of B come from the sequence (1, 6, 120, 5040, 362880, 39916800, 6227020800, 1307674368000, 355687428096000, 121645100408832000, ...)
The ratio between adjacent values of B (6, 20, 42, 72, 110, 156, 210, 272, 342, ...) grows faster than prime numbers grow, so conceptually speaking there's plenty of room here for encoding the prime numbers. (C=0.359344964622775339841352348439200241924659634 would encode the first 18 primes.)
That said... this *is* cute. But it also has a bit of a deus ex machina flavor. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 03:22, 2 July 2022 (UTC)
* You are right. If a magician pulls a rabbit out of a hat, then we know for sure that he putted it there before. The same is here. To pull prime numbers out of ''C'', we need to secretly put them before. The only difference is that a magician's hat usually has one false bottom, ''C'' has infinitely many false bottoms. [[User:Alexei Kopylov|Alexei Kopylov]] ([[User talk:Alexei Kopylov|talk]]) 04:33, 2 July 2022 (UTC)
== Bug in Fortran code ==
The Fortran code by Gordon Goodsman contains
CALL PSURGE(SCHAR) !During preparation of the first batch of bits.
This usage of PSURGE as a subroutine disagrees with the declaration of PSURGE as a function of type LOGICAL. One possible fix is to replace the call by
PSRG = PSURGE(SCHAR)
where PSRG is of type LOGICAL (a variable is set but never used afterwards).
Other than this, the code is a very good contribution.
| |||