Talk:Extensible prime generator

Ada

Extensible: The task name uses the word "extensible", but the description of the task does not explain what that means. I believe the task description is quite clear, but the Ada-solution I submitted was flagged with a red box that that solution was "not extensible", while other, very similar solutions, such as the one in C, where not flagged that way. By my understanding, either solution is actually extensible. If your usage of "extensible" is different, the task description would need a proper definition what it means to be "extensible".

Sorry. I see someone has removed the incorrect flag I put on Ada by mistake. --Paddy3118 (talk) 19:49, 16 April 2014 (UTC)

Off by one?

Rust and Seed7 disagree with the others regarding the 10.000th prime.--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.--PureFox (talk) 22.35, 6 January 2019 (UTC)

See the webpage   primes.utm.edu/small/10000.txt     (at the very bottom).     -- 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.--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. --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. 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.