PARI's commands - Page 55

3.14159 · 2010-08-17, 00:41

Quote:

Originally Posted by CRGreathouse

Do you know what "it" is?

To be honest, I have no idea.

3.14159 · 2010-08-17, 00:44

Alright. To get back to the amateur siever. It's going to be a long and complicated script, and I'm afraid my current known commands aren't going to cut it.

CRGreathouse · 2010-08-17, 00:52

Quote:

Originally Posted by 3.14159

Alright. To get back to the amateur siever. It's going to be a long and complicated script, and I'm afraid my current known commands aren't going to cut it.

It should be about 6 lines long.

Maybe later we can work on it. Right now I'm doing other stuff, and I'm sure you're pretty well fried.

3.14159 · 2010-08-17, 01:15

Quote:

Originally Posted by CRGreathouse

It should be about 6 lines long.

Maybe later we can work on it. Right now I'm doing other stuff, and I'm sure you're pretty well fried.

Alright. Notify whenever ready.

Also: I unwittingly discovered this: 254164423 * 3700! + 1 is prime (11607 digits)

CRGreathouse · 2010-08-17, 01:35

Quote:

Originally Posted by 3.14159

Alright. Notify whenever ready.

SWEET, I finished the Gerbicz primorial function. Now if I can just get this

sieve code to work, I'll be good to go... it's only 200 lines long, why does it cause me such trouble?

Radishes, radishes, radishes.

3.14159 · 2010-08-17, 01:45

Quote:

Originally Posted by CRGreathouse

SWEET, I finished the Gerbicz primorial function. Now if I can just get this

sieve code to work, I'll be good to go... it's only 200 lines long, why does it cause me such trouble?

Ah, another day in the life of the average programmer..

An 11607-digit k * n! + 1 happens to be a personal record for primes of that type.

CRGreathouse · 2010-08-17, 02:40

OK, so funny story.

This project has two main parts: the sieve, which factors numbers into a specialized form, and the end function, which takes 256 bits of sieve data plus the number and determines what value it has (possibly stopping early if it can tell it won't be good enough). I had been over the end function pretty closely, checking it against 'known-good' code, so I was pretty sure the problem was with the sieve. I was having trouble figuring out just where... memory corruption? Bad interactions between the three types of primes it deals with? Etc.

So what was the problem? A tiny (~4 character) section of a line of code checking whether the value was a record or not.

So the first unoptimized version is now running. It's 20 times faster than the compiled script (to 1e8), which is slightly faster than the original script. Now I just need to clean up the code, remove all the testing apparatus, and start optimizing. As written, it will get faster and faster compared to the original code as it goes to higher ranges, but I think I can get another 20% improvement by removing multiples of small squares... it's not hard to prove that, beyond 49, all members of my sequence are squarefree.

3.14159 · 2010-08-17, 03:08

So, Charles: Is work on the sieve I want to construct beginning? I think I can do the forstep loops.

axn · 2010-08-17, 03:46

Quote:

Originally Posted by 3.14159

So, Charles: Is work on the sieve I want to construct beginning? I think I can do the forstep loops.

Do you know how to write pseudocode? Try writing the logic in a language-independent way. Best way to learn programming is by doing it.

3.14159 · 2010-08-17, 13:06

Quote:

Originally Posted by axn

Do you know how to write pseudocode? Try writing the logic in a language-independent way. Best way to learn programming is by doing it.

Depends on language. I can definitely perform:
"print(x)"

3.14159 · 2010-08-17, 15:14

For the search for k * 4900! + 1; I set it to trial division only: I set it to between 4900 and 10⁶. I'll only test the numbers that have no factors below 10⁶.
(There are about 20k-30k candidates.)
I figured it would become too slow if I decided to do some deep TF. (I tested it at around the 50M range for the pmax.)

Quote:

Originally Posted by CRGreathouse

So what was the problem? A tiny (~4 character) section of a line of code checking whether the value was a record or not.

Need to proofread more often, there.

2010-08-17, 00:44	#596
3.14159 May 2010 Prime hunting commission. 2⁴·3·5·7 Posts	Alright. To get back to the amateur siever. It's going to be a long and complicated script, and I'm afraid my current known commands aren't going to cut it. Last fiddled with by 3.14159 on 2010-08-17 at 00:45

2010-08-17, 03:08	#602
3.14159 May 2010 Prime hunting commission. 690₁₆ Posts	So, Charles: Is work on the sieve I want to construct beginning? I think I can do the forstep loops. Last fiddled with by 3.14159 on 2010-08-17 at 03:08

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Why do I sometimes see all the <> formatting commands when I quote or edit?	cheesehead	Forum Feedback	3	2013-05-25 12:56
Passing commands to PARI on Windows	James Heinrich	Software	2	2012-05-13 19:19
Ubiquity commands	Mini-Geek	Aliquot Sequences	1	2009-09-22 19:33
64-bit Pari?	CRGreathouse	Software	2	2009-03-13 04:22
Are these commands correct?	jasong	Linux	2	2007-10-18 23:40

2010-08-17, 02:40	#601
CRGreathouse Aug 2006 5979₁₀ Posts	OK, so funny story. This project has two main parts: the sieve, which factors numbers into a specialized form, and the end function, which takes 256 bits of sieve data plus the number and determines what value it has (possibly stopping early if it can tell it won't be good enough). I had been over the end function pretty closely, checking it against 'known-good' code, so I was pretty sure the problem was with the sieve. I was having trouble figuring out just where... memory corruption? Bad interactions between the three types of primes it deals with? Etc. So what was the problem? A tiny (~4 character) section of a line of code checking whether the value was a record or not. So the first unoptimized version is now running. It's 20 times faster than the compiled script (to 1e8), which is slightly faster than the original script. Now I just need to clean up the code, remove all the testing apparatus, and start optimizing. As written, it will get faster and faster compared to the original code as it goes to higher ranges, but I think I can get another 20% improvement by removing multiples of small squares... it's not hard to prove that, beyond 49, all members of my sequence are squarefree.