This directory contains files of prime numbers. They are sorted into two categories: primes useful to the Blum Blum Shub PRNG algorithm (congruent with both MOD 3 and MOD 4), and those primes which are not. Each filename identifies its contents, as below... C_50.hexp = Congruent primes from the 50th million N_50.hexp = Non-congruent from the same range The extension *.hexp stands for 'HEX Prime', which is non-standard, the contents being ASCII text. Like so, however, that they might be easily machine-recognized. Rows are delimited by newline chars only (DEC 10, HEX 0A). Absent are any useless charriage returns (DEC 13, HEX 0D), their now long-obsolete purpose being to trigger a separate realy on ancient-of-days mechanical TTY machines. Thereby are file sizes reduced by roughly a half a megabyte each. Two example sets of initial and final few lines read as below. Said examples derive from C_40.hexp and N_40.hexp respectively. Width: 8 Tally: 500131 2E48ED63 2E48ED7B 2E48EDB1 -------- 2D10A3B9 2D10A401 2D10A431 Width: 8 Tally: 499869 2E48ED6D 2E48ED85 2E48ED8B -------- 2D10A3B1 2D10A465 2D10A477 Note as ow the first line of each is informative: [A] the column byte-width of primes on all subsequent lines; [B] the total count of said subsequent lines. Both values present as decimal integers (not HEX). Column byte-width is might vary between any two given files. As would be the case if one file contained primes occupying more or fewer digits. Anyhow, say you want the 234567th prime listed in C_40.hexp. In a text editor, you'd find it on line 234568, with a HEX value of 2DB67D4B. A program you'd coded would need to calculate its file position thus: 24 + 234566 * 9 = 2111118. In said formula: 24 is the first line's width inclusive of an invisible newline; 234566 are the number of primes prior; 9 is the column width of 8 plus a newline. Byte-location 2111118 in the file is the terminating newline of line 234566 containing the prime just prior. Read in the next line (or next 8 bytes, as you prefer) and you'll have the prime which you seek. Want to skip all that math? Simply jump into the file at any location 16 bytes less than the file's own size. From there, read in 16 bytes, which will contain somewhere within it a prime bracked between newlines. It may sometimes happen, that many upper rows display as HEX padded with one or more zeros on left. This would be so as to align with larger primes needing additional columns lower dowin in the file. Filenames with numerics 50 and smaller were sourced from online: . Those files came in ZIP format, extracting to such filenames as: primes50.txt. Aside from not being pre-sorted for whether Blum Blum Shub compatible, the files were also bloody enormous: 10.4 MB each. This due to how they were organized internally. Lots of whitespace was present. Even so, they were still quite easily parsed via software. And so, hence my own greatly size-reduced offerings. Those parsed into pairs, as detailed above. My plan is to add yet another 50 million or so primes to this collection: filenames such as , and so forth. Those to be got, necessarily, from a yet another source. How I parsed them was via a set of programs which I coded entirely by hand in ANS Forth. It's all part of a hobby project of mine. All of it coded likewise in ANS Forth. A data-encryption system titled, the acronym being by George Orwell's '1984'. Later on, I might possibly parse out a further one or two sister file sets: binary (*.binp), and decimal (*.dec). The unaltered source code runs equally well on both Linux (gForth) and Windows (SwiftForth, VFX) alike. Plugging away at it is helping to keep my few remaining brain cells limber during retirement.