Nevermind. I answered my own question. Okay: I can mess with the params as I wish? Cool.

Wait: Does it use the F/trial division switch?

Also: Found 268 * 4200! + 1 (13399 digits). A prime with a prime number of digits. Excellent.

[CODE]plength(n) = forstep(x=(10^n)+1,10^(n+1),[2],if(isprime(x),return(x)))[/CODE]

for some reason this isn't working properly. I can get it to work as planned but then it might mess up someone else if they use it.

realized why now doh.

sm: It looks good to me. This is A003617(n+1), right?

Faster would be
[code]plength(n)=nextprime(10^n)[/code]

[QUOTE=CRGreathouse;226873]sm: It looks good to me.[/QUOTE]

well it isn't! and I know why.

[CODE](15:42) gp > plength(n) = forstep(x=(10^n)+1,10^(n+1),[2],if(isprime(x),return(x)))
%471 = (n)->forstep(x=(10^n)+1,10^(n+1),[2],if(isprime(x),return(x)))
(15:43) gp > plength(3)
%472 = 1009
(15:43) gp >[/CODE]

is the original result

[CODE](15:45) gp > plength(n) = forstep(x=(10^(n-1))+1,10^(n),[2],if(isprime(x),return(x)))
%473 = (n)->forstep(x=(10^(n-1))+1,10^(n),[2],if(isprime(x),return(x)))
(15:45) gp > plength(3)
%474 = 101
(15:45) gp >[/CODE]

see the difference the reason the original was working weird is I didn't account for 1-9 so when i put in plength(3) the first on started at 10^3 which already has 4 digits when I compensate I get the correct value.

I also did this with your knowledge:

[CODE]sumdigits(n) = if(n%9!=0,return(n%9),return(n%9+9))[/CODE]

but you might think it's kinda lame.

[QUOTE]0 [B]1 2 3 4 5 6 7 8 9[/B]
[B]1[/B] [COLOR="Red"]1 2 3 4 5 6 7 8 9[/COLOR]
[B]2[/B] [COLOR="Orange"]2 4 6 8 1 3 5 7 9[/COLOR]
[B]3[/B] [COLOR="Yellow"]3 6 9 3 6 9 3 6 9[/COLOR]
[B]4[/B] [COLOR="green"]4 8 3 7 2 6 1 5 9[/COLOR]
[B]5[/B] [COLOR="Blue"]5 1 6 2 7 3 8 4 9[/COLOR]
[B]6[/B] [COLOR="indigo"]6 3 9 6 3 9 6 3 9[/COLOR]
[B]7[/B] [COLOR="violet"]7 5 3 1 8 6 4 2 9[/COLOR]
[B]8[/B] [COLOR="Magenta"]8 7 6 5 4 3 2 1 9[/COLOR]
[B]9[/B] 9 9 9 9 9 9 9 9 9[/QUOTE]

if i did my math correct this is the sum of digits multiplication table.

[QUOTE=science_man_88;226878]I also did this with your knowledge:

[CODE]sumdigits(n) = if(n%9!=0,return(n%9),return(n%9+9))[/CODE]

but you might think it's kinda lame.[/QUOTE]

This only works for n < 100. For larger numbers, try
[code]dsum(n,b=10)={
my(s=0);
while(n>=b,
s += n%b;
n \= b;
);
s+n
};
addhelp(dsum, "dsum(n,{b=10}): Sum of the base-b digits of n.");[/code]

A more efficient version would work mod 100 or 1000 using a lookup table, and use divrem rather than \ and %. A really efficient version would split the values into two parts of roughly equal length until they became 'small' (say, less than a googol).

[QUOTE=science_man_88;226876]see the difference the reason the original was working weird is I didn't account for 1-9 so when i put in plength(3) the first on started at 10^3 which already has 4 digits when I compensate I get the correct value.[/QUOTE]

Because you didn't explain what the function was supposed to do, you didn't have a help message, and the name wasn't self-explanatory, I couldn't tell that this was an error rather than the intended behavior. :smile:

[QUOTE=3.14159;226844]Also: Found 268 * 4200! + 1 (13399 digits). A prime with a prime number of digits. Excellent.[/QUOTE]

Primes with a prime number of digits... hmm. I wonder in what sense this has positive density. Of course it has natural density 0, as a subset of the primes; I don't know what its upper logarithmic density would be. If that's not positive, is there a finer measure? I wonder.

The set is 'weird' because it has huge gaps, then lots of relatively densely packed elements: no members (strictly) between 10^114 - 153 and 10^126 + 679, a gap of length ~10^126, but then > 3.44218 * 10^123 members in the next 10^126.