Problem Statement

The sieve of Eratosthenes: you've been there; done that; have the T-shirt. The sieve of Eratosthenes was ancient history when Euclid was a schoolboy. You are ready for something less than 3000 years old. You are ready for The sieve of Sundaram. Starting with the ordered set of +ve integers, mark every third starting at 4 (4;7;10...). Step through the set and if the value is not marked output 2*n+1. So from 1 to 4 output 3 5 7. 4 is marked so skip for 5 and 6 output 11 and 13. 7 is marked, so no output but now also mark every fifth starting at 12 (12;17;22...) as per to 10 and now mark every seventh starting at 17 (17;24;31....) as per for every further third element (13;16;19...) mark every (9th;11th;13th;...) element. The output will be the ordered set of odd primes. Using your function find and output the first 100 and the millionth Sundaram prime. The faithless amongst you may compare the results with those generated by The sieve of Eratosthenes. Comment on the Sundaram Sieve In case casual readers and programmers read the above blurb and get the impression that something several thousand years newer must needs be better than the "old" Sieve of Eratosthenes (SoE), do note the only difference between the Sieve of Sundaram (SoS) and the odds-only SoE is that the SoS marks as composite/"culls" according to all odd "base" numbers as is quite clear in the above description of how to implement it and the above linked Wikipedia article (updated), and the SoE marks as composite/"culls" according to only the previously determined unmarked primes (which are all odd except for two, which is not used for the "odds-only" algorithm); the time complexity (which relates to the execution time) is therefore O(n log n) for the SoS and O(n log log n) for the SoE, which difference can make a huge difference to the time it takes to sieve as the ranges get larger. It takes about a billion "culls" to sieve odds-only to a billion for the SoE, whereas it takes about 2.28 billion "culls" to cull to the same range for the SoS, which implies that the SoS must be about this ratio slower for this range with the memory usage identical. Why would one choose the SoS over the SoE to save a single line of code at the cost of this much extra time? The Wren comparison at the bottom of this page makes that clear, as would implementing the same in any language.

Let's start with the solution:

sundaram=: {{
 sieve=. -.1{.~k=. <.1.2*(*^.) y
 for_i. 1+i.y do.
  f=. 1+2*i
  j=. (#~ k > ]) (i,f) p. i+i.<.k%f
  if. 0=#j do. y{.1+2*I. sieve return. end.
  sieve=. 0 j} sieve
 end.
}}


   P=: sundaram 1e6
   10 10$P
  3   5   7  11  13  17  19  23  29  31
 37  41  43  47  53  59  61  67  71  73
 79  83  89  97 101 103 107 109 113 127
131 137 139 149 151 157 163 167 173 179
181 191 193 197 199 211 223 227 229 233
239 241 251 257 263 269 271 277 281 283
293 307 311 313 317 331 337 347 349 353
359 367 373 379 383 389 397 401 409 419
421 431 433 439 443 449 457 461 463 467
479 487 491 499 503 509 521 523 541 547
   {:P
15485867