PARI's commands

[CRGreathouse]

Originally Posted by 3.14159

6? O rly?

I don't care to go through the thread to count the number of times, but my best off-the-top-of-my-head guess would be 7 or 8. But 6 seemed a safer bet.

[CRGreathouse]

em2(x,n,a)={
	forstep(b=lift(Mod(-1,x)/n),10^a,x, print(b))
};

nonmem(a,x,m,b)={
	for(n=a,x,
		if(n=!mem(a,x,m,b), print(n))
	)
};

mem(a,x,m,b) = {
	forprime(p=a,x,
		print(em2(p,m!,b))
	);
};

So given some x, n, and a, em2 prints a bunch of stuff to the screen and returns nothing. mem then takes this nothing, converts it to a 0, and prints it to the screen. This process repeats once for every prime in [a, x] -- the a and x passed to mem, that is, not those passed to em2. After this loop, mem returns nothing.

nonmem computes this nothing, with no changes, x - a + 1 times, each time checking if n is equal to the nothing, converted to a zero and negated. So all n except for 1 (if it is in the range) are printed.

So calling nonmem causes mem to be called x - a + 1 times, each time calling em2 times (total times), which results in em2's inner print statement being called about times (total very roughly

times).

In short: calling nonmem causes a whole lot of numbers to whiz by on the screen, most of them the same as earlier numbers, mostly because the same calculation is being done that was already done before.

As far as "does it do what it's supposed to do?", I would guess not -- but it's hard to say for sure.

[3.14159]

Originally Posted by CRGreathouse

In short: calling nonmem causes a whole lot of numbers to whiz by on the screen, most of them the same as earlier numbers, mostly because the same calculation is being done that was already done before.

As far as "does it do what it's supposed to do?", I would guess not -- but it's hard to say for sure.

Correct. It failed to function properly. As for the latter, em2 does what it is supposed to do.

[CRGreathouse]

If em2 is doing what it's supposed to, then mem is clearly wrong -- it shouldn't expect a return value from a function that doesn't return anything.

[3.14159]

Originally Posted by CRGreathouse

If em2 is doing what it's supposed to, then mem is clearly wrong -- it shouldn't expect a return value from a function that doesn't return anything.

Well, I did say mem needs some fixing.

[3.14159]

Hey: I should get back to the sieve project for the arithmetic progression prime searches. The trial division switch for PFGW just doesn't cut it.

[3.14159]

The most recent idea is to fix mem. I will begin with Liftmodm1, which basically gives lift(Mod(-1,x)/(n)), for any x and any n. Liftmodm1 should be incorporated into mem instead of em2.

Scratch that. Liftmod has too few arguments. I'll pin a return on em2.

[3.14159]

Now that I have pinned a return value instead of printing, I'll see what I can do for mem.

[3.14159]

mem repeatedly loops, and this must be resolved. That means, I'll apply the (and) condition as necessary, so there is no loop. Let's see how this works out.

[3.14159]

Let's try: k * 11! + 1; Apply the and condition for primes 13 through 349..

Scratched: This would also loop and repeat duplicates endlessly.

[3.14159]

Okay: It cannot use vectors and loops, as any method using these is dreadfully inefficient.

The closest to a sieve I can manage is trial-dividing each to 10⁶ and testing those which have no factors below 10⁶.

3814 * p(65)#⁴⁰ + 1 is prime. (≈5115-5117 digits)