Testing new Ranges for Sierpinski/Riesel

[wombatman]

Yeah, looks it goes outside of the allocated memory:

The most common ways to corrupt heap are:

writing past the end of allocation
freeing memory that you didn't allocate
freeing something twice.

Interesting :)

[rogue]

Originally Posted by pepi37

I try to edit code, add ( ) as you say ,and compile again under Linux
Compilation process is fine but srbieve crash at start...

Don't know. I just don't have time to work on this right now.

[wombatman]

No worries. I was just looking around to try and understand the code, and that part confused me. It frankly looks like it's right as is, and I was wrong about needing to add the parentheses.

[KEP]

Just a heads up for everyone considering to do new bases. I'm currently very far in the process of creating optimized srbase.ini files for ALL partially and ALL untested bases. I expect within the next 6 weeks, to be able to post the srbsieve.ini files needed to run the untested and partially tested bases

[KEP]

Originally Posted by KEP

Just a heads up for everyone considering to do new bases. I'm currently very far in the process of creating optimized srbase.ini files for ALL partially and ALL untested bases. I expect within the next 6 weeks, to be able to post the srbsieve.ini files needed to run the untested and partially tested bases

This is not gonna happen, within the 6 weeks as hoped. It just simply takes too long to sieve to optimal sievedepth for each phase of S1023. As soon as each phase of S1023 has reached optimal sievedepth, then it is almost as little as a few hours of copy paste, before the .ini files needed to run srbsieve, is all created. New ETA is somewhere right after christmas.

@Rogue: Could I ask, that the next release (hopefully completed before I releases the 321 srbsieve.ini files I'm currently creating) of srbsieve as Step 1, test for even bases k=1 for all NewPGen sieved n's? ... NewPGen is a great program in many ways, but for some weird reason, all bases fail to contain k=1 in the fixed n sieve and therefor k=1 could have a prime for n<=NewPGen nMax. It's a minor thing, I know, but people who aren't used to work with NewPGen or srbsieve, cannot be expected to be able to figure out, that k=1 may hold 2 primes or still remain at n=nMax (usually n=25K), even though k=1 has a prime wich NewPGen could have found if NewPGen did not avoid k=1 in NewPGens sieve.

[rogue]

Originally Posted by KEP

This is not gonna happen, within the 6 weeks as hoped. It just simply takes too long to sieve to optimal sievedepth for each phase of S1023. As soon as each phase of S1023 has reached optimal sievedepth, then it is almost as little as a few hours of copy paste, before the .ini files needed to run srbsieve, is all created. New ETA is somewhere right after christmas.

@Rogue: Could I ask, that the next release (hopefully completed before I releases the 321 srbsieve.ini files I'm currently creating) of srbsieve as Step 1, test for even bases k=1 for all NewPGen sieved n's? ... NewPGen is a great program in many ways, but for some weird reason, all bases fail to contain k=1 in the fixed n sieve and therefor k=1 could have a prime for n<=NewPGen nMax. It's a minor thing, I know, but people who aren't used to work with NewPGen or srbsieve, cannot be expected to be able to figure out, that k=1 may hold 2 primes or still remain at n=nMax (usually n=25K), even though k=1 has a prime wich NewPGen could have found if NewPGen did not avoid k=1 in NewPGens sieve.

I do not understand your request, please restate.

[gd_barnes]

k=1 does not need to be tested for any bases. The script can start at k=2.

[KEP]

Originally Posted by gd_barnes

k=1 does not need to be tested for any bases. The script can start at k=2.

I think I remember that you told me the same thing, quite a few years ago. However, since 1*1018^1+1 is prime, why shouldn't it be part of the conjecture?

@Rogue: I'll get back to you, if it turns out that k=1 has to be tested if k=1 isn't GFN or trivial, otherwise just forget what I previously posted

[KEP]

Originally Posted by KEP

Just a heads up for everyone considering to do new bases. I'm currently very far in the process of creating optimized srbase.ini files for ALL partially and ALL untested bases. I expect within the next 6 weeks, to be able to post the srbsieve.ini files needed to run the untested and partially tested bases

Last and final delay.

I've made huge progress over the last month. However, IT WILL NOT be untill late january, before I have the 70% sievedepth calculated srbsieve.ini files created.

I currently needs to sieve 3 more phases for S1023 and from there on, I need about 5 reallife days of sieving (~8000 remaining phases for all other remaining untested/partially tested bases) to p=1M, to account for the different removal rate of composites.

As soon as the final sieving of the 3 remaining phases is done and the sieving of the remaining phases (all other untested/partially tested bases) to p=1M is done, then it will be only a matter of days. I really hope that it will not be as late as january 31st 2016, however do not expect any srbsieve.ini files for currently untested/partially tested bases prior to that date.

If you consinder using srbsieve, now is time to get acquainted with how NewPGen and NewPGen's fixed n function works. Also it may be time that Gary and Ian thinks about how to get the remaining untested bases for conjectured k<=k-limit-of-sr2sieve started. All conjectures less than the limits of sr2sieve, may benefit from running srbsieve to a low n and therefrom switch to sieving using sr2sieve instead of srsieve.

Take care and happy new year.

[gd_barnes]

Originally Posted by KEP

I think I remember that you told me the same thing, quite a few years ago. However, since 1*1018^1+1 is prime, why shouldn't it be part of the conjecture?

@Rogue: I'll get back to you, if it turns out that k=1 has to be tested if k=1 isn't GFN or trivial, otherwise just forget what I previously posted

k=1 is ALWAYS GFN or trivial. That's why we don't consider it. Yes some bases will have a GFN prime like S1018 but many will not. See the pages where it says "k=1 is a GFN with no known prime.". S1014 and S1016 are examples. See a list of known GFN primes for bases <=1030 up to n=2^17 at http://www.noprimeleftbehind.net/crus/GFN-primes.htm. See that S1014 and S1016 have none. The largest known prime for bases <= 1030 is 150^2048+1. There are unlikely to be any others for n>2^17. (I believe that other projects have searched these to n=2^20.)

[gd_barnes]

Just a heads up for everyone considering to do new bases. I'm currently very far in the process of creating optimized srbase.ini files for ALL partially and ALL untested bases. I expect within the next 6 weeks, to be able to post the srbsieve.ini files needed to run the untested and partially tested bases

Originally Posted by KEP

Last and final delay.

I've made huge progress over the last month. However, IT WILL NOT be untill late january, before I have the 70% sievedepth calculated srbsieve.ini files created.

I currently needs to sieve 3 more phases for S1023 and from there on, I need about 5 reallife days of sieving (~8000 remaining phases for all other remaining untested/partially tested bases) to p=1M, to account for the different removal rate of composites.

As soon as the final sieving of the 3 remaining phases is done and the sieving of the remaining phases (all other untested/partially tested bases) to p=1M is done, then it will be only a matter of days. I really hope that it will not be as late as january 31st 2016, however do not expect any srbsieve.ini files for currently untested/partially tested bases prior to that date.

If you consinder using srbsieve, now is time to get acquainted with how NewPGen and NewPGen's fixed n function works. Also it may be time that Gary and Ian thinks about how to get the remaining untested bases for conjectured k<=k-limit-of-sr2sieve started. All conjectures less than the limits of sr2sieve, may benefit from running srbsieve to a low n and therefrom switch to sieving using sr2sieve instead of srsieve.

Take care and happy new year.

I don't understand your first post here and then your update. So are you really testing ALL of the remaining bases, for example R280 and S280? I hope not. The prime files alone would be petabytes. I don't plan to administer such monstrosities.

If you are only doing S1023, then that is OK.