Score 194
1%(2^(n*30+16)%(n*30+17))*(1%(2^(n*30+22)%(n*30+23))*(1%(2^(n*30+28)%(n*30+29))*(1%(2^(n*30+12)%(n*30+13))*(1%(2^(n*30+6)%(n*30+7))*(1%(2^(n*30+10)%(n*30+11))*(1%(2^(n*30+18)%(n*30+19))*(-18)+8)+4)-6)-16)+6)+6)+n*30+17+702*0^(((n-360)*(n-523)*(n-654)*(n-941))^2)
Verification, generation code
This is golfing down the excellent solution of Max Kubierschky, who said they will no longer spend time updating their answer. See their answer for an explanation of the strategy. The formula here is largely the same, but was shortened by removing repetition and introducing cancellations.
Branching
The main improvement is the arithmetic formula used to branch on a condition:
if b1: t1
else: t2
Previously, this was done as b1*t1+(1-b1)*t2
. This meant the condition b1
needed to be repeated twice, which was costly because the condition of Fermat-primality used a relatively long formula.
We instead regroup b1*t1+(1-b1)*t2
into b1*(t1-t2)+t2
. Instead of repeating the condition b1
, we repeat the output t2
. So, we arrange to make `t2 be short.
As used, one of the branches just gives a number (the successfully found prime), which the other branches into further conditions to continue the search.
if b1: t1
else:
if b2: t2
else:
if b3: t3
else: ...
Our method has the no-result t2
repeated twice rather than t1
, but we can fix this by negating the condition b2
so that we can interchange t1
and t2
We make it so that the twice-repeated t1
is just a number, while the once-repeated t2
is the long branch. We do this by negative the condition b
to checking non-primality rather than primality. This is done by replacing the 1/stuff
check for stuff==1
to instead be 1%stuff
for stuff!=1
(in both cases, we know stuff!=0
).
Doing this recursive expansion, we further find that it has terms like t1-t2
that subtract two potential outputs. These can be simplified. Because each possible output has form 30*n+d
, we can cancel like (30*n+17)-(30*n+23)==-6
, saving many instances of writing 30*n+
.
Error fixing
We use a variation of an idea suggested by Arnauld to fix the faulty cases in a shorter way, using 32 characters not counting parens.
+702*0^(((n-360)*(n-523)*(n-654)*(n-941))^2)
There are four non-prime outputs, and a brute-force search finds that adding 702
to each one makes them prime and distinct from all other outputs. We use an indicator function of being in those four cases, and adding 702
times that indicator. The indication function uses 0^
to check ==0
for a product of n-k
for each failed input k
. (If we can't rely on 0^0==1
, we can use 1/(1+_)
as a slightly longer alternative for ``0^_`.)
Potential improvements
Other potential approaches might hide errors in a more efficient way by adaptively adjusting the numbers checked and the base of the pseudoprime, as suggested by in comments by Max Kubierschky.
Score: 181
1%(4^(n*15+8)%(n*30+17))*(1%(4^(n*15+11)%(n*30+23))*(1%(4^(n*15+14)%(n*30+29))*(1%(4^(n*15+6)%(n*30+13))*(1%(8^(n*10+2)%(n*30+7))*(1%(4^(n*15+5)%(n*30+11))*(4-1%(4^(n*15+9)%(n*30+19))*9)+2)-3)-8)+3)+3)*2+n*30+17+702*0^(n%941%654%523%360)
Verification
This includes some hand-found optimizations. First, the faulty cases are checked in a shorter way found by Sisyphus, as 0^(n%941%654%523%360)
. This evaluates to 1
exactly for the exceptional inputs n
of 360, 523, 654, 941
and zero otherwise. This mod chain works because each value happens to be less than double the previous one, including if we append 1000
to the end.
Other misc fixes uses that some values could be written shorter in base 10. Some of the expressions within the primality checks like 2^(n*30+16)
could be shortened like 4^(n*15+8)
. The various difference values were all even and could be written halved with a *2
later. A +stuff*(-18)
was changed to -18*stuff
.
0<=n<1000
instead of0<n<=1000
? \$\endgroup\$n
which is a number from 1 to 1000 that should output the 1000 primes \$\endgroup\$f(x)>f(y)
for allx>y
\$\endgroup\$^
? This would allow using rational numbers, which I'm not sure you want. \$\endgroup\$n
'th prime for anyn
, not just up to 1000. I suspect this would be shorter than hardcoding information for 1000 primes. It may also be possible to modify Lopsy's primality-testing approach to give the n'th prime. \$\endgroup\$