my first test, testing S1057 to n=3000, with k from 2 to 50 000 was really stupid.
I abandonned the idea of running the newbase script on it.
For testing purpose, I will test R71 from k=2 to k=500 000 on both srbsieve and the newbase script.
According to [url]http://www.noprimeleftbehind.net/crus/tab/CRUS_tab.htm[/url] R71 hasn't started.

I've posted PFGW 3.7.10 to sourceforge. I only have the Windows version posted now and the Mac and Linux versions will follow later. You must use this version with the script to ensure correct results with sorptive. In fact versions between 3.4.0 and 3.7.9 might produce the wrong results in the pl_xxx.txt files. The problem is that some numbers would not be written to pl_MOB.txt (with the new-base.txt script) that should have been. It is possible that some numbers might (although very unlikely) have made it to pl_remain.txt that really should have been in pl_MOB.txt. Fortunately it will be very easy to find any that are wrong by simply running srbsieve against a range and seeing if the pl_MOB.txt it produces has k that are still remaining.

I found bug in srbsieve.
On first post you say
[QUOTE]You can specify as many of these as you want, although there is a practical limit due to newpgnew limits with sieving[/QUOTE]
I made 60, and srbsieve just exited.. So I reduce number until 50 ( and with 50) srbsieve works OK. But if it is 51.th in srbsieve.ini: it exits and do no job.

[QUOTE=pepi37;407852]I made 60, and srbsieve just exited.. So I reduce number until 50 ( and with 50) srbsieve works OK. But if it is 51.th in srbsieve.ini: it exits and do no job.[/QUOTE]

There is a limit of 50 in the code. I could change the program to exit nicely, but I see little reason that anyone would sieve to such a high n with newpgen when using this program.

Ok , I go off the scale :)

Please can you clarify this

phase= is used to sieve in steps. The first value is the upper n for the phase[COLOR=Red][U][B] followed by the number of concurrent k [/B][/U][/COLOR]to sieve and finally by the maxp of the sieving.

What doest it mean, and how to calculate that number to be optimal in all phase stages?

It will sieve a certain # of k at a time. So if you have, say, 10,000 k to go through, you can choose to do 1000 at a time for a given phase. Maybe it's a little faster? I haven't played with it much.

[QUOTE=wombatman;407871]It will sieve a certain # of k at a time. So if you have, say, 10,000 k to go through, you can choose to do 1000 at a time for a given phase. Maybe it's a little faster? I haven't played with it much.[/QUOTE]

Great, since there is only 90 left( in my case), and I set to 1000 it is then OK :smile:
Thanks for explanation!

uint32_t for p_max in source code seems not enough, should be uint64_t.

[CODE]...
Status (02:50:50): Completed phase 4: 28 remaining
ERROR: 64 bit sieve is limited to primes below 2^51.[/CODE]srbsieve.ini:
[CODE]...
phase=120,50000,500000
phase=330,30000,3000000
phase=1200,20000,30000000
phase=4400,10000,300000000
phase=10000,5000,3000000000
[/CODE]

[CODE]#ifdef WIN32
sprintf(buffer, "del %s sr_b.pfgw pfgw.ini", inFileName);
system("pfgw64 -Cquiet -f0 sr_b.pfgw > nul");
system(buffer);
#else
sprintf(buffer, "rm %s sr_b.pfgw pfgw.ini", inFileName);
system("./pfgw64 -Cquiet -f0 sr_b.pfgw > nul");
system(buffer);
#endif[/CODE]Another small addition - nul should be /dev/null in second case.

Yes, got same error four times ( on four cores)

Status (09:25:33): Completed phase 5: 13 remaining
ERROR: 64 bit sieve is limited to primes below 2^51.

my ini file

[QUOTE]phase=1000,200,10000000
phase=2000,100,30000000
phase=4000,100,100000000
phase=8000,100,300000000
phase=12000,100,1000000000
phase=15000,100,3000000000
phase=20000,100,4000000000
phase=25000,100,5000000000[/QUOTE]

Okay. I think I've got everyone's suggestions implemented.

One mistake, I have /dev/nul instead of /dev/null. I'll update if another bug is found.

My house had a short power outage. Is there a good way to try and pick back up with srbsieve, at least in terms of having it remove all the k's that have a prime found, or, even better, near the last n it was searching? :smile:

[QUOTE=wombatman;407979]My house had a short power outage. Is there a good way to try and pick back up with srbsieve, at least in terms of having it remove all the k's that have a prime found, or, even better, near the last n it was searching? :smile:[/QUOTE]

You can take the created files and remove the n from the original list. That might be a lot of work though. I should probably have it checkpoint after each phase is complete.

Could there a line in the ini file--something like LastN=""? That way, someone could just pick up from there or enter in the appropriate n value. Alternatively, a checkpoint would work fine too.

Edit: Is there a good way to restart it with the already proven k's removed? With, say, the pl_prime or using the pl_remain files that are created? That would be better than starting over completely.

[QUOTE=wombatman;407987] With, say, the pl_prime or using the pl_remain files that are created? That would be better than starting over completely.[/QUOTE]

Fantastic idea!
And I also noticed one thing: if I start srbsieve for test and exit : then when I try to edit srbsieve.ini : got lock worning: and until I kill that cmd windows that is invisible ( kill it in the task manager) cannot edit anything.

Last: please could some one compile it for 64 bit Linux: I try but lot of warnings, and there is no binaries at end :(

Rogue one thing is still big mystery for me. Speed on different basses.
On first post you say
[QUOTE]
Note that this range of 5M took a little over 6 hours.[/QUOTE]So you process on [B]one[/B] core at base 3 up to 25K with little over 6 hours.

In my case I started with only 89 candidates left and 5 hours later I still have it 20 and test is up 13.8K

I know the base 3 is very prime base, but so much difference is impossible ( or not)

I take you settings , and yesterday on S708 take my settings but there is no significant difference.
Running on I7 -2700K under Win 7 -x64 on 4Ghz.
Any advise?

P.S with this speed I will finish my base around 1.5 days from start. on four cores...

[QUOTE=pepi37;408014]Rogue one thing is still big mystery for me. Speed on different basses.
On first post you say
So you process on [B]one[/B] core at base 3 up to 25K with little over 6 hours.

In my case I started with only 89 candidates left and 5 hours later I still have it 20 and test is up 13.8K

I know the base 3 is very prime base, but so much difference is impossible ( or not)

I take you settings , and yesterday on S708 take my settings but there is no significant difference.
Running on I7 -2700K under Win 7 -x64 on 4Ghz.
Any advise?

P.S with this speed I will finish my base around 1.5 days from start. on four cores...[/QUOTE]

Consider: How big a number is 708^10000? How big is 3^25000?

[QUOTE=VBCurtis;408015]Consider: How big a number is 708^10000? How big is 3^25000?[/QUOTE]

On base 3 and on exponent 25K length is 11933 digits
On base 708 and on exponent 25K length is 71258 digits

x7 is factor :) so it will be at least 7x more time....
Thanks VBCurtis

[QUOTE=wombatman;407987]Could there a line in the ini file--something like LastN=""? That way, someone could just pick up from there or enter in the appropriate n value. Alternatively, a checkpoint would work fine too.

Edit: Is there a good way to restart it with the already proven k's removed? With, say, the pl_prime or using the pl_remain files that are created? That would be better than starting over completely.[/QUOTE]

I ended up just making a quick and (very) dirty python script to generate a file with all the n's in a given range (like n=3000 to 4000) based on the k's that remain in pl_remain.txt. That should work alright for now, and I can resume the file with pfgw if the power goes out again.

[QUOTE=pepi37;408017]x7 is factor :) so it will be at least 7x more time....
[/QUOTE]
If M is the size factor, it will be ~ M[SUP]3[/SUP] more time, times ratio of series densities.

[QUOTE=Batalov;408020]If M is the size factor, it will be ~ M[SUP]3[/SUP] more time, times ratio of series densities.[/QUOTE]
And M is what? ( or in my case what is X time more?)

I am tempted to stop all, make deep sieve and finished with LLR :)
It looks faster :)

I've added recovery capability to this version, but it is completely untested. You will need to start a range from scratch so that it can build the checkpoint file as it executes. If it does work out of the box (which would surprise me), then there are conditions under which it cannot recover, such as incomplete writes to files. I can only think of that happening if there is a hardware problem, power less, or a software bug in my code.

I will test it with R708 as a new base up to n=25k. :smile:

As you requested, started from scratch

[QUOTE]D:\SRBASE1>srbsieve
Status (00:00:00): Started with 499 terms
Status (00:00:00): Removed 168 terms due to trivial factorization
Status (00:00:00): Removed 0 terms due to MOB
Status (00:00:00): Removed 0 terms due to MOB
Status (00:00:00): Removed 84 terms from newpgen for n = 1: 247 remaining
Status (00:00:00): Removed 36 terms from newpgen for n = 2: 211 remaining
Status (00:00:00): Removed 30 terms from newpgen for n = 3: 181 remaining
Status (00:00:00): Removed 24 terms from newpgen for n = 4: 157 remaining
Status (00:00:00): Removed 17 terms from newpgen for n = 5: 140 remaining
Status (00:00:00): Removed 24 terms from newpgen for n = 6: 116 remaining
Status (00:00:00): Removed 17 terms from newpgen for n = 7: 99 remaining
Status (00:00:01): Removed 17 terms from newpgen for n = 8: 82 remaining
Status (00:00:01): Removed 9 terms from newpgen for n = 9: 73 remaining
Could Not Find D:\SRBASE1\srbsieve.ckpt
[/QUOTE]end then - exit

So it looks like software bug in your code- option 3 :)

I got the same thing:[CODE]Could Not Find C:\Users\Ben\Desktop\SrbSieve\R708\srbsieve.ckpt[/CODE]

I fixed that obvious mistake.

[QUOTE=rogue;408043]I fixed that obvious mistake.[/QUOTE]

and make another one :)

Could Not Find d:\SRBASE1\pfgw.ini
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
Error opening file sr_b.pfgw
Status (00:00:01): Completed phase 1: 73 remaining
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
Error opening file sr_b.pfgw
Status (00:00:03): Completed phase 2: 73 remaining
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
Error opening file sr_b.pfgw
Status (00:00:09): Completed phase 3: 73 remaining
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
Error opening file sr_b.pfgw
Status (00:00:25): Completed phase 4: 73 remaining

Deleted the input file in the wrong place.

[QUOTE=rogue;408052]Deleted the input file in the wrong place.[/QUOTE]

Still not working.
But you got some progress

You can stop srbsieve , but only once
Second time , program crash.
I found root of problem
Program ( in my case) searching for[COLOR=Red][B] sr_808.pfgw[/B][/COLOR] ( I do S808 base)
but srbsieve writes file named [COLOR=Red][B]sr_b.pfgw[/B][/COLOR] : so it has to be renamed.
Same is for sieve input
Program search for [COLOR=Red][B]sieve.in[/B][/COLOR]
but in directory is file[COLOR=Red][B] sr_b.in
[/B][COLOR=Black][/COLOR]
[/COLOR]

And still have old problem, some K that said is removed are removed, other said also are not :(
I has no logic to some K is removed some are not, but all need to be.

[QUOTE]08/16/15 02:54:43 srsieve started: 51 <= n <= 80, 3 <= p <= 500000
08/16/15 02:54:43 removed candidate sequence[COLOR=Blue] 7785*808^n+1[/COLOR] from the sieve[B][COLOR=Blue] removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence [COLOR=Red]6894*808^n+1[/COLOR] from the sieve [B][COLOR=Red]not removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence [COLOR=Blue]8719*808^n+1[/COLOR] from the sieve [COLOR=Blue][B]removed[/B][/COLOR]
08/16/15 02:54:43 removed candidate sequence [COLOR=Blue]9709*808^n+1[/COLOR] from the sieve [B][COLOR=Blue]removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence [COLOR=Blue]7702*808^n+1[/COLOR] from the sieve [B][COLOR=Blue]removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence[COLOR=Blue] 7377*808^n+1 [/COLOR]from the sieve [B][COLOR=Blue]removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence [COLOR=Blue]7159*808^n+1[/COLOR] from the sieve [B][COLOR=Blue]removed[/COLOR][/B]
08/16/15 02:54:43 removed candidate sequence [B][COLOR=Red]10879*808^n+1[/COLOR][/B] from the sieve [COLOR=Red][B]not removed[/B][/COLOR]
08/16/15 02:54:43 removed candidate sequence [B][COLOR=Red]10572*808^n+1[/COLOR][/B] from the sieve [COLOR=Red][B]not removed[/B][/COLOR]
08/16/15 02:54:43 srsieve stopped: at p=500000 because --pmax was reached.
[/QUOTE][QUOTE]6079*808^n+1
6409*808^n+1
6592*808^n+1
6703*808^n+1
6705*808^n+1
6802*808^n+1
6849*808^n+1
[B][COLOR=Red]6894*808^n+1[/COLOR][/B]
6942*808^n+1
7053*808^n+1
7059*808^n+1
7281*808^n+1
7872*808^n+1
7926*808^n+1
7948*808^n+1
8037*808^n+1
8269*808^n+1
8356*808^n+1
8559*808^n+1
8586*808^n+1
8941*808^n+1
8955*808^n+1
9057*808^n+1
9612*808^n+1
9688*808^n+1
9709*808^n+1
9769*808^n+1
9918*808^n+1
10201*808^n+1
10287*808^n+1
10302*808^n+1
10377*808^n+1
[COLOR=Red]10572*808^n+1[/COLOR]
10656*808^n+1
10768*808^n+1
[COLOR=Red]10879*808^n+1[/COLOR]
10884*808^n+1
11118*808^n+1
11332*808^n+1
11419*808^n+1
11461*808^n+1
11472*808^n+1
11671*808^n+1
11698*808^n+1
11727*808^n+1
11952*808^n+1
12036*808^n+1
12058*808^n+1
12073*808^n+1
[/QUOTE]

srsieve will remove all sequence if it finds a factor for all n in the range being sieved.

As for the other issue, srsieve creates sr_608.pfgw, but I copy to sr_b.pfbw as the program has to change the first line of the file.

Sieving is started with sieve.in, but when it terminates it will write to sr_608.pfgw. Recovery starts with sr_608.pfgw rather than from the beginning.

I'd have to run a test to see why it crashes.

Just to add what I'm seeing (which should be similar or the same), I get this error when I try to restart after stopping in the middle of PRP checking:
[CODE]Status (00:00:00): Started recovery at phase 1 with 3860 terms
ERROR: Failed to open input file `sr_708.pfgw'.
Could Not Find C:\Users\Ben\Desktop\SrbSieve\R708\sieve.in[/CODE]

So the checkpoint is correct, and sr_b.pfgw is present when srbsieve is started. Once started, though, the above error is thrown, and sr_b.pfgw is overwritten to nothing.

Due latest news, I so very small check
Srbsieve from some reason say that 10*708^27+1[B] is prime[/B]

But independently llr64, pfgw says it [B]is composite
[/B]
10*708^27+1 is not prime. RES64: A46C206476D17E99. OLD64: 02C4612D64747BC7 Time : 58.039 ms.

D:\PGFW>pfgw64 -d -q"10*708^27+1"
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

Switching to Exponentiating using GMP
10*708^27+1 is composite: RES64: [A46C206476D17E99] (0.0001s+0.0002s)

ok, testing at a small scale : S71, n upto 80 with k from 2 to 500 000, both with srbsieve (07/22 version) and new base script.

So far srbsieve tell me there is 22034 sequences left @ n=80, will know about newbase in a few hours.

[QUOTE=pepi37;408076]Due latest news, I so very small check
Srbsieve from some reason say that 10*708^27+1[B] is prime[/B]

But independently llr64, pfgw says it [B]is composite
[/B]
10*708^27+1 is not prime. RES64: A46C206476D17E99. OLD64: 02C4612D64747BC7 Time : 58.039 ms.

D:\PGFW>pfgw64 -d -q"10*708^27+1"
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

Switching to Exponentiating using GMP
10*708^27+1 is composite: RES64: [A46C206476D17E99] (0.0001s+0.0002s)[/QUOTE]

How far did you sieve with NewPGen? I'm asking in terms of n, what was your smallest and what was your highest n sieved using NewPGen for S708? Did you sieve to at least n=27 (or higher) using NewPGen? Did you at all n's let NewPGen sieve up to squareroot of the highest k/n pair?

I've had no problems with srbsieve finding wrong primes and if the users fail to understand how important it is to not sieve to a higher n than NewPGen can sieve within reasonable time to squareroot of highest k/n pair, then srbsieve will mistakenly believe that you have a prime at the inappropriately sieved n.

Ps. I'm now going to do my own test of srbsieve latest version and run S708 to n=2500 and compare to Gary's list.

For reference, I added 10*708^27+1 to factordb, and its first factor is 18960572317

[QUOTE=KEP;408079]How far did you sieve with NewPGen? I'm asking in terms of n, what was your smallest and what was your highest n sieved using NewPGen for S708? Did you sieve to at least n=27 (or higher) using NewPGen? Did you at all n's let NewPGen sieve up to squareroot of the highest k/n pair?

I've had no problems with srbsieve finding wrong primes and if the users fail to understand how important it is to not sieve to a higher n than NewPGen can sieve within reasonable time to squareroot of highest k/n pair, then srbsieve will mistakenly believe that you have a prime at the inappropriately sieved n.

Ps. I'm now going to do my own test of srbsieve latest version and run S708 to n=2500 and compare to Gary's list.[/QUOTE]

As tutorial say ( I followed tutorial step by step) I do from N=1 to N=50 , every step sieved to 20000000088 ,and let Newpgen finished job.
Since I do on quad core: I setup four directory with ranges that are not overlapping 1-7090 7091-14180 14181-21270 21271-28360 and do for all 4 ranges same step in sieving with NewPgen
Is that mistake I made?

[QUOTE=pepi37;408081]As tutorial say ( I followed tutorial step by step) I do from N=1 to N=50 , every step sieved to 20000000088 ,and let Newpgen finished job.
Since I do on quad core: I setup four directory with ranges that are not overlapping 1-7090 7091-14180 14181-21270 21271-28360 and do for all 4 ranges same step in sieving with NewPgen
Is that mistake I made?[/QUOTE]

Yes pepi37, that is exactly the mistake you have made. I can tell you, that I have no prime for 10*708^27+1, in fact k=10 still remains at n=660. You and others have to understand, that for any base and any n, you have to let NewPGen sieve up to squareroot of the highest k/n pair. If you go and set an insane stop at p= value to something like p=1000000000000000 then tell's NewPGen to stop at n=6 for S708, then you should have ok sievefiles, because then NewPGen will automatically stop sieving the given n value, once NewPGen has sieved to squareroot of given n and given k range. You have overdone NewPGen and undersieved by many years of sieving and that way your results got unreliable and caused a friendly fire against both Mark and srbsieve, while Mark nor srbsieve has done any mistake worth blaming them for.

I'm going to announce what I find, once I complete testing S708 to n=2500, but I do expect a match between srbsieve, version released 15th august 2015 and the files Gary uploaded.

Take care!

ok, now the newbase script has finished, and the number of remaining base is the same, 22034.

here is the file to compare the result : [url]http://www.filedropper.com/compare-srbsievenewbase[/url] (size is about 2 MB)

[QUOTE=pepi37;408081]As tutorial say ( I followed tutorial step by step) I do from N=1 to N=50 , every step sieved to 20000000088 ,and let Newpgen finished job.
Since I do on quad core: I setup four directory with ranges that are not overlapping 1-7090 7091-14180 14181-21270 21271-28360 and do for all 4 ranges same step in sieving with NewPgen
Is that mistake I made?[/QUOTE]

I don't know how you read that from this:

[quote]npgfile= is used to specify output files from newgpen's fixed n sieve. The first value is the n for which the range was sieved. The second is the name of the file that was output from newpgen. You can specify as many of these as you want, although there is a practical limit due to newpgnew limits with sieving. [COLOR="Red"]newpgen will sieve until p exceeds sqrt(maxk*b^n+c) and it will terminate on its own[/COLOR]. That is great for this search because it means that all values remaining after sieving are prime which means that none of the values that passed sieving will require a primality test. You will not want to go to a very high n as sieving takes longer as n increases and the effectiveness of removing k is diminished. [COLOR="green"]n=22 is about as far as one should go for Riesel base 3. Higher bases will result in going to a lower n.[/COLOR][/quote]

For the sentence in red, it is imperative that you let newpgen finish on its own. You cannot terminate. If you terminate newpgen before it reaches that max, then you cannot use that input file for srbsieve. srbsieve assumes that you have followed that rule because it guarantees primality of those numbers. srbsieve will not verify that you followed the rule.

For the sentence in green, I know understand why you ran into that problem when you had more than 50 input files to srbsieve. Nobody could have that many input files and properly sieve with newpgen. sqrt(maxk*b^50) is well beyond the capabilities of newpgen when b > 2.

Please let me know if this is clear. Also ask any questions you might have about using srsieve properly.

1. Please I apologize to all: especially to Mark, GDBarnes, and any other person that is affected because my unknown of mathematics, and skill I need to know to start new base. Yes, I am sorry, and I will never do it again.
2. Please unreserved all my bases: once, in time ( if came) I will take one base and try... ( but until that time..)
3. But last , I ask any of you, that know math far better then me to in answer give me
- appropriate setup for base S708 but from scratch.
So give me number of sieved files, give me setup in NewPgen and give me basic math: how you calculate those values for S708.
Can you do it?
Dont give me formula, give me formula and result so I can follow your work.

Then when I look at those results I will send to any of you who knows math setup for next base. I will not reserve it, I will not publish it, or I will not search it, just setup so you can verify or not , tell me is there error or not.
Can I ask you this favor?
Once more, please accept my apologize..
And last: I never terminate NewPgen: it always done to the end, with my setup was over in 40 minutes, so I wait until last n was finished and message appear NewPgen reach limit.,

[QUOTE=pepi37;408088]1. Please I apologize to all: especially to Mark, GDBarnes, and any other person that is affected because my unknown of mathematics, and skill I need to know to start new base. Yes, I am sorry, and I will never do it again.
2. Please unreserved all my bases: once, in time ( if came) I will take one base and try... ( but until that time..)
3. But last , I ask any of you, that know math far better then me to in answer give me
- appropriate setup for base S708 but from scratch.
So give me number of sieved files, give me setup in NewPgen and give me basic math: how you calculate those values for S708.
Can you do it?
Dont give me formula, give me formula and result so I can follow your work.

Then when I look at those results I will send to any of you who knows math setup for next base. I will not reserve it, I will not publish it, or I will not search it, just setup so you can verify or not , tell me is there error or not.
Can I ask you this favor?
Once more, please accept my apologize..[/QUOTE]

No problem Pepi, I have helped Reb understand things before and I would also like to help you. It is most welcome, that we get more users (new as well as old) that start up bases. So in a few minutes I'll send you a PM and all I ask of you, is to think of wich base to test/practice on :smile: ... welcome on board my friend, looking forward to be working with you in PM or here :wink:

[QUOTE=KEP;408089]No problem Pepi, I have helped Reb understand things before and I would also like to help you. It is most welcome, that we get more users (new as well as old) that start up bases. So in a few minutes I'll send you a PM and all I ask of you, is to think of wich base to test/practice on :smile: ... welcome on board my friend, looking forward to be working with you in PM or here :wink:[/QUOTE]

KEP, I have no other word to say then THANKS
I was learned that world open even iron gate :smile:

well,708^6 has 18 digits, 708^7 has 20 digits. i would suggest to limit yourself to 6 or seven files, as rogue recommend in the first post that k*b^n+c be slightly above 1e20. so dépending of the k....

[QUOTE=firejuggler;408091]well,708^6 has 18 digits, 708^7 has 20 digits. i would suggest to limit yourself to 6 or seven files, as rogue recommend in the first post that k*b^n+c be slightly above 1e20. so dépending of the k....[/QUOTE]

Maybe a simpler way would be to sieve for n until p > 1e9 when the sieve stops on its own. That would guarantee that newgpen finds all primes <= 60 bits. p > 1e10 works better for smaller bases.

KEP send me all data I need
For now, I do testing S810 unofficial, without any reservations, to see how much time I need.
Then I will see what future will get.
Once more.. apologize Rogue.

I have started to test S708 to n=6 and compare the results with KEP.

[QUOTE=rebirther;408095]I have started to test S708 to n=6 and compare the results with KEP.[/QUOTE]
I am waiting to N become 7 then i will also start.

I have restarted a couple of my bases as I couldn't be sure I had fully finished the last n from newpgen. Just to be clear, though, I will be taking R201, R297, R303, R598, and R708 (all new bases) to n=25k. Thanks!

[QUOTE=wombatman;408104]I have restarted a couple of my bases as I couldn't be sure I had fully finished the last n from newpgen. Just to be clear, though, I will be taking R201, R297, R303, R598, and R708 (all new bases) to n=25k. Thanks![/QUOTE]
I think it will be good to make this reservation in reservation thread, not here?

S708
 

hi,
i did S708 to n=2500 as a test with srbsieve
704 k´s remaining

[QUOTE=pepi37;408105]I think it will be good to make this reservation in reservation thread, not here?[/QUOTE]

I did in the reservation threads already. I just wanted to make sure there was no confusion as to whether I was going to finish them or not. :smile:

R708
 

hi,
i did R708 to n=5000 as a test with srbsieve
828 k´s remaining

[QUOTE=lalera;408106]hi,
i did S708 to n=2500 as a test with srbsieve
704 k´s remaining[/QUOTE]
In reality 702 k remain.

Somehow*, you have k=1 in the pl_remain file (but 1*708^1+1 is prime) and you set up maxk incorrectly (it should have been CK-1, not CK).
Otherwise it is a match.

*Properly compiled/configured srbsieve doesn't leave k=1. Unfortunately, as has been already noted, srbsieve allows for many operator's mistakes. Some of the oldest Unix jokes iirc contained this: "User error: replace user and press any key to continue." :rolleyes: This is [B]not[/B] to be taken personally, I hope.

[QUOTE=Batalov;408109]In reality 702 k remain.

Somehow*, you have k=1 in the pl_remain file (but 1*708^1+1 is prime) and you set up maxk incorrectly (it should have been CK-1, not CK).
Otherwise it is a match.

*Properly compiled/configured srbsieve doesn't leave k=1. Unfortunately, as has been already noted, srbsieve allows for many operator's mistakes. Some of the oldest Unix jokes iirc contained this: "User error: replace user and press any key to continue." :rolleyes: This is [B]not[/B] to be taken personally, I hope.[/QUOTE]

Well then I'm going to cancel my work on S708 to n=2500, since that ultimately proves that srbsieve is reliable. Now Gary, please lift the advise from not using srbsieve and again advocate the use of srbsieve. I'm sure that Pepi and others has learned their lessons :smile:

[QUOTE=Batalov;408109]In reality 702 k remain.

Somehow*, you have k=1 in the pl_remain file (but 1*708^1+1 is prime) and you set up maxk incorrectly (it should have been CK-1, not CK).
Otherwise it is a match.

*Properly compiled/configured srbsieve doesn't leave k=1. Unfortunately, as has been already noted, srbsieve allows for many operator's mistakes. Some of the oldest Unix jokes iirc contained this: "User error: replace user and press any key to continue." :rolleyes: This is [B]not[/B] to be taken personally, I hope.[/QUOTE]

Mean 701? :)
In his txt file has 703 ( minus 1*708 and last CK) gives 701 as Barnes say :)

703 and 701, yes.
But not 49 :razz:

[QUOTE=Batalov;408112]703 and 701, yes.
But not 49 :razz:[/QUOTE]
Everyone makes mistake ( like somebody who I know go alone hiking) :davieddy:

[QUOTE=Batalov;408109]In reality 702 k remain.

Somehow*, you have k=1 in the pl_remain file (but 1*708^1+1 is prime) and you set up maxk incorrectly (it should have been CK-1, not CK).
Otherwise it is a match.

*Properly compiled/configured srbsieve doesn't leave k=1. Unfortunately, as has been already noted, srbsieve allows for many operator's mistakes. Some of the oldest Unix jokes iirc contained this: "User error: replace user and press any key to continue." :rolleyes: This is [B]not[/B] to be taken personally, I hope.[/QUOTE]

why does the newbases-script start with k=1 ?
i wondered myself a little to start with srbsieve k=1 because
newpgen starts with k=2
with which k should i start srbsieve ?
that with the CK-1 i did not know - i took it from the crus webpage
i do use the compilate for windows from mr. rodenkirch
in your post #74 you wrote
"#define PRId64 "lld" - That solves the compilation problem on linux"
this is not really the solution ...
there are some code changes necessary - like string conversion - maybe char const*
instead of char* and so on... (i googled a little) but i am not a programmer

[QUOTE=lalera;408106]hi,
i did S708 to n=2500 as a test with srbsieve
[B]704[/B] k´s remaining[/QUOTE]
[QUOTE=pepi37;408111]
In his txt file has [B]703[/B][/QUOTE]
Talk amongst yourselves. :rolleyes:

[QUOTE=lalera;408114]why does the newbases-script start with k=1 ?[/QUOTE]
Why wouldn't it?
[QUOTE=lalera;408114]with which k should i start srbsieve ?[/QUOTE]
1 of course. Unless you are contributing to R3.

[QUOTE=lalera;408114]there are some code changes necessary - like string conversion - maybe char const*
instead of char* and so on... (i googled a little) but i am not a programmer[/QUOTE]
That's an advice that cancels itself, I am afraid.

[QUOTE=lalera;408114]why does the newbases-script start with k=1 ?
i wondered myself a little to start with srbsieve k=1 because
newpgen starts with k=2
with which k should i start srbsieve ?
that with the CK-1 i did not know - i took it from the crus webpage
i do use the compilate for windows from mr. rodenkirch
in your post #74 you wrote
"#define PRId64 "lld" - That solves the compilation problem on linux"
this is not really the solution ...
there are some code changes necessary - like string conversion - maybe char const*
instead of char* and so on... (i googled a little) but i am not a programmer[/QUOTE]

The proper solution is to find the standard header that has the define. I don't know while file it is on linux. Is it in inttypes.h or stdypes.h?

I'm not concerned about compiler warnings (where const char * or char const * or const char const * is needed) unless the compiler is so strict that it makes those into errors.

In the next release I will ensure that the newpgen file is sieved deeply enough. If not, I will terminate srbsieve and you will either have to continue sieving until it is sieved deeply enough or remove the file. I could add code to do a primality test on the newpgen file but as I have stated elsewhere pfgw has difficulty proving primality when the number is less than 40 bits or so in size. Since I have suggested going to 60 bits or more using newpgen, that should not be a problem.

Also, since the latest version of llr now seems to support srsieve output and the feature to stop on the first prime for a given k, I might be able to switch to that. It should be slightly faster than pfgw (as it won't require a separate primality test). I won't do that now as it is more important to get the recovery logic working.

[QUOTE=rogue;408116]...In the next release I will ensure that the newpgen file is sieved deeply enough. If not, I will terminate srbsieve and you will either have to continue sieving until it is sieved deeply enough or remove the file....[/QUOTE]

Could I humbly request that srbsieve print out something like "NO! BAD USER! YOU STAY THERE UNTIL YOU FINISH YOUR NEWPGEN." if the newpgen file isn't sieved enough?

[QUOTE=KEP;408110]Well then I'm going to cancel my work on S708 to n=2500, since that ultimately proves that srbsieve is reliable. Now Gary, please lift the advise from not using srbsieve and again advocate the use of srbsieve. I'm sure that Pepi and others has learned their lessons :smile:[/QUOTE]

I had already ran S708 to n=2500. See the reservations for bases 501-1030 thread. I show 701 k's remaining. This is one different than what Serge showed. Serge, you might check your k's remaining against the file that I attached in that thread.

[QUOTE=KEP;408110]Well then I'm going to cancel my work on S708 to n=2500, since that ultimately proves that srbsieve is reliable. Now Gary, please lift the advise from not using srbsieve and again advocate the use of srbsieve. I'm sure that Pepi and others has learned their lessons :smile:[/QUOTE]

Done. See the news thread. (I never suggested stopping it for base 3 since I had independently verified it for that base.)

I also sent a PM to Mark about possibly putting error checking for NewPGen sieve depth and anything else that we can think of into srbsieve. Hopefully we can prevent as many user errors as possible in the future.

I've mentioned this before: Running new bases at CRUS can be very difficult! It's not for the faint of heart, especially large-conjectured bases.

[QUOTE=gd_barnes;408142]Done. See the news thread. (I never suggested stopping it for base 3 since I had independently verified it for that base.)

I also sent a PM to Mark about possibly putting error checking for NewPGen sieve depth and anything else that we can think of into srbsieve. Hopefully we can prevent as many user errors as possible in the future.

I've mentioned this before: Running new bases at CRUS can be very difficult! It's not for the faint of heart, especially large-conjectured bases.[/QUOTE]

:tu:

I have, just to be clear, kept running with srbsieve my R3 reservations. Even though it might burden you with more work, it appears that my optimized sieve values and increase from 6 phases to 18 phases for R3, might have triggered yet another speedincrease (compared to Rogues suggestion of phases and optimal sievedepth). One, that could be such efficient that we might hit a very big milestone. I'll know more in a weeks time :smile:

[QUOTE=gd_barnes;408141]I had already ran S708 to n=2500. See the reservations for bases 501-1030 thread. I show 701 k's remaining. This is one different than what Serge showed. Serge, you might check your k's remaining against the file that I attached in that thread.[/QUOTE]
I did not count lines; I [I]diffed the files[/I] and there were two extra lines in lalera's. Additionally, my own run of srbsieve didn't diff from yours. Since lalera said that there were "704", minus 2, the result was "702". My mistake was to trust [URL="http://mersenneforum.org/showpost.php?p=408106&postcount=149"]lalera's count[/URL].

[QUOTE=gd_barnes;408141]I had already ran S708 to n=2500. See the reservations for bases 501-1030 thread. I show 701 k's remaining. This is one different than what Serge showed. Serge, you might check your k's remaining against the file that I attached in that thread.[/QUOTE]

Gary, I have tested this base to n=2500 and have 702 remain, the only difference is 1*708^n+1 in the file. So it should be 701. Why is this number left?

[QUOTE=lalera;408108]hi,
i did R708 to n=5000 as a test with srbsieve
828 k´s remaining[/QUOTE]
I can DC this data.
For starters, 10000, 20000, 30000 are listed twice; CK=41121 is listed as "remain"ing k. So it is already 827, not 828.
There are also some differences of squares, cubes and seventh powers.

[COLOR="Blue"]P.S. 9216*708^n-1 = (96*708^h-1)*(96*708^h+1), with h=n/2, for even n; and divisible by 709 for odd n.[/COLOR]

Any ideas for having srbsieve auto-compute the sieve depth?

The time spent sieving should be in the vicinity of 5% of the time it will take to test the entire file for primality. At very low exponents, this might be better set to 10%.

If there's a way to estimate how long it would take the PFGW the whole file (perhaps number of entries in the sieve multiplied by the time it takes to PFGW a candidate at the midpoint of the exponents), multiplying that by 10% and stopping srsieve at that time (rather than depth) should work. Of course, sieving reduces the number of tests in the sieve, and I have no idea what the right way to compensate for that is. Perhaps sieve to 100*maxn^2 (pulled from my &^%*), count the number of items in the sieve, then do this calculation?

That won't be ideal for bases like R3 that lose a bunch of k's to primes, as those sieve files have most of their tests run well below the midpoint of the exponent range. But, it still prevents cases like my first couple tries at using srbsieve, where I ended up having it sieve for longer than it took the resulting file to PFGW completely. If one wanted to allow tinkering, one could make the 10% a setting in the .ini, so users can adjust the relative time spent in sieve; this allows stuff like R3 to run at 7%, or even lower, to compensate for the high frequency of primed k's.

Edit- much simpler is to find time to test a midpoint-exponent candidate, and sieve until time per factor equals that time. I think srsieve has that option as a flag?

[QUOTE=VBCurtis;408199]Edit- much simpler is to find time to test a midpoint-exponent candidate, and sieve until time per factor equals that time. I think srsieve has that option as a flag?[/QUOTE]

Indeed it does!

[CODE]-S --stop-rate X Stop when it takes X seconds to eliminate a candidate.[/CODE]

And let someone who knows how Linux works help that Rogue compile srbsieve for Linux ( 64 bit)
I got testing S 810. On one machine it will be done at aprox ten days: on three will be done in 3.3 days :)
So anyone?

[QUOTE=paleseptember;408203]Indeed it does!

[CODE]-S --stop-rate X Stop when it takes X seconds to eliminate a candidate.[/CODE][/QUOTE]

good idea - but if there are many concurrent tasks (more than physical cores)
it would stop too soon

then use a higher X

[QUOTE=LaurV;408214]then use a higher X[/QUOTE]

do you know the real load of the machine ?
(an example: if the load is high you need to set -S 30 and
if the load is low to medium you need to set -S 10 or so ...)
p=xxx? would be better but who knows how to set it correct for each base and
exponent ?

[CODE]-S --stop-rate X Stop when it takes X seconds to eliminate a candidate.[/CODE]

That works fine for higher n, but for low n it doesn't because you want a removal rate of "x per second" instead of "seconds per x".

[QUOTE=pepi37;408212]And let someone who knows how Linux works help that Rogue compile srbsieve for Linux ( 64 bit)
I got testing S 810. On one machine it will be done at aprox ten days: on three will be done in 3.3 days :)
So anyone?[/QUOTE]

I cannot compile for linux as I do not have a linux machine. I have already explained earlier in this thread how to compile for linux. All you should need is the GNU Compiler Chain (gcc).

[QUOTE=lalera;408213]good idea - but if there are many concurrent tasks (more than physical cores)
it would stop too soon[/QUOTE]

If the target time were found on the same machine with the same load, it would not matter how many tasks were running, as the result would still be "sieve until PFGW is faster on an avg candidate."

[QUOTE=rogue;408223]I cannot compile for linux as I do not have a linux machine. I have already explained earlier in this thread how to compile for linux. All you should need is the GNU Compiler Chain (gcc).[/QUOTE]

gcc *.cpp -lstdc++ -O2 -m64 -o srbsieve
main.cpp: In function ‘void getInputs()’:
main.cpp:160:40: error: expected ‘)’ before ‘SCNu64’
main.cpp: In function ‘void removeTrivial()’:
main.cpp:273:34: error: expected ‘)’ before ‘PRId64’
main.cpp: In function ‘void removeGFN()’:
main.cpp:330:27: error: expected ‘)’ before ‘PRId64’
main.cpp: In function ‘void removeMOB()’:
main.cpp:423:30: error: expected ‘)’ before ‘PRId64’
main.cpp: In function ‘void processNewpgenFile(uint32_t)’:
main.cpp:481:27: error: expected ‘)’ before ‘PRId64’
main.cpp: In function ‘void doPhase(int)’:
main.cpp:519:31: error: expected ‘)’ before ‘PRId64’
main.cpp: In function ‘void call_srsieve(uint32_t, uint32_t, uint64_t)’:
main.cpp:555:46: error: expected ‘)’ before ‘PRIu64’
main.cpp: In function ‘void prp_test_ABC_file()’:
main.cpp:601:32: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
main.cpp: In function ‘void output_remain(char*)’:
main.cpp:710:29: error: expected ‘)’ before ‘PRId64’

I have compiled srsieve ,srsieve1 and srsieve2 for Linux without any problem on same machine: so it looks like I have whatever I need

This is your last code before adding recovery...

[QUOTE=VBCurtis;408199]That won't be ideal for bases like R3 that lose a bunch of k's to primes, as those sieve files have most of their tests run well below the midpoint of the exponent range. But, it still prevents cases like my first couple tries at using srbsieve, where I ended up having it sieve for longer than it took the resulting file to PFGW completely. If one wanted to allow tinkering, one could make the 10% a setting in the .ini, so users can adjust the relative time spent in sieve; this allows stuff like R3 to run at 7%, or even lower, to compensate for the high frequency of primed k's.[/QUOTE]

No that won't be ideal. I think that you should wait a few days and see how much faster my srbsieve.ini file is. I have 18 phases and sieve to approximately 2% of the candidates remaining (This was found to be optimal, by using srsieve and sieve the given n-range for each phase, so the value wich I use is accurate to the removal rate on R3). I'm not sure, how much faster it is to run with 18 phases, but if it is as fast as it looks like, then I will be able to do about [B]100G[/B] (maybe more)for base 3 per year on my Hasswell (QuadCore). Also I should add, that my sievedepth, wich for phase 1 (33000 k's) is only p=70000 (n=33 to n=100).

[B]@Rogue:[/B] Since I'm sieving to n=32 using NewPGen and might sieve to n=33 for the next tests for R3, could you please have the limit at nothing lower than 33 NewPGen files, for base 3?

[QUOTE=KEP;408232]No that won't be ideal. I think that you should wait a few days and see how much faster my srbsieve.ini file is. I have 18 phases and sieve to approximately 2% of the candidates remaining (This was found to be optimal, by using srsieve and sieve the given n-range for each phase, so the value wich I use is accurate to the removal rate on R3). I'm not sure, how much faster it is to run with 18 phases, but if it is as fast as it looks like, then I will be able to do about [B]100G[/B] (maybe more)for base 3 per year on my Hasswell (QuadCore). Also I should add, that my sievedepth, wich for phase 1 (33000 k's) is only p=70000 (n=33 to n=100).

[B]@Rogue:[/B] Since I'm sieving to n=32 using NewPGen and might sieve to n=33 for the next tests for R3, could you please have the limit at nothing lower than 33 NewPGen files, for base 3?[/QUOTE]

haswell - [url]https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29[/url]

[QUOTE=VBCurtis;408226]If the target time were found on the same machine with the same load, it would not matter how many tasks were running, as the result would still be "sieve until PFGW is faster on an avg candidate."[/QUOTE]

... looks like ... "speech theory" ...

[QUOTE=pepi37;408229]
main.cpp:710:29: error: expected ‘)’ before ‘PRId64’

I have compiled srsieve ,srsieve1 and srsieve2 for Linux without any problem on same machine: so it looks like I have whatever I need[/QUOTE]

You will need to find the header that has a #define for that then modify the code to include it in main.cpp. I suggest searching /usr/include for that string.

[QUOTE=KEP;408232][B]@Rogue:[/B] Since I'm sieving to n=32 using NewPGen and might sieve to n=33 for the next tests for R3, could you please have the limit at nothing lower than 33 NewPGen files, for base 3?[/QUOTE]

I see no reason for force that requirement.

[QUOTE=rogue;408237]I see no reason for force that requirement.[/QUOTE]

Great, thank you :tu:

[QUOTE=rogue;408236]You will need to find the header that has a #define for that then modify the code to include it in main.cpp. I suggest searching /usr/include for that string.[/QUOTE]

Got it!
Thanks!
Only got one error, but with build binaries:
Now I run test what same data from Windows for reference!

[QUOTE=pepi37;408253]Got it!
Thanks!
Only got one error, but with build binaries:
Now I run test what same data from Windows for reference![/QUOTE]

Which header did you need to include?

[QUOTE=rogue;408254]Which header did you need to include?[/QUOTE]
None.
It looks like my gcc was "old" it was 4.7
I now install 4.9 and it compile whit that one error.
I found that yours decalration are same as in MiniGW inttypes.hr , and those I get in Linux are little different
( file is here[URL]http://www.dropbox.com/s/s4yj44kho6g5ba9/inttypes.h?dl=0[/URL] )

So if I follow correctly
[CODE]# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
....
# define PRId64 __PRI64_PREFIX "d"[/CODE]

will be equivalent of

# define PRId64 "ld" ?

I am correct?

It attachment is cross- reference between Windows, Linux on I5-3570K and on Linux on Haswell.
All three has 7328 primes, remains are same, as GFN and MOB and trivial.
But I seen just one "error" on print screen on all three "windows" ( look at copy-scrren.txt)

It says[CODE] Completed phase 5: [COLOR=Red][B]159[/B][/COLOR] remaining ( on Linux and Windows),[/CODE] but both Linux have 158 remain.
I dont know what was status of Windows at that time, since it is now on 8.8K .
In "win" directory are Pgen files, and settings for first set of S810 in srbsieve.ini ( I divide work on four cores)

UPDATE
I look at task on four cores on Windows
On first core it shows[B][COLOR=Red] one prime more[/COLOR][/B] ( show 119, have 118) , on other show[B][COLOR=Red] correct[/COLOR] [/B]number
So it looks like "missing prime is 1*810^n+1" since I start from 2 in srbsieve.ini
810^1+1 is prime! (3 decimal digits, Trial divisions) Time : 0.002 ms.

And since cross reference was from first set, I think all is OK.

[QUOTE=rogue;408236]You will need to find the header that has a #define for that then modify the code to include it in main.cpp. I suggest searching /usr/include for that string.[/QUOTE]
FWIW...I encountered a similar issue when compiling PRPnet on the noprimeleftbehind.net server (which has a very old gcc). It seems the C standard formatting macros are included by default by some compilers, but not (apparently) some versions of gcc.

The header [i]is[/i], in fact, being included already, but the desired macros are "turned off" when __STDC_FORMAT_MACROS is not defined.

The fix is to add "-D__STDC_FORMAT_MACROS" to CPPFLAGS in the Makefile. This sets the compiler flag that turns on the format macros. In my case, for compiling PRPnet, CPPFLAGS ended up looking like this:
[code]
[b]Before:[/b]
CPPFLAGS=-c -g -m64 -Wall
[b]After:[/b]
CPPFLAGS=-c -g -m64 -D__STDC_FORMAT_MACROS -Wall
[/code]
The actual line might be different for sr*sieve (I haven't ever tried compiling them myself so I wouldn't know), but a similar change should do the trick.

A while back when I asked Lennart about this, he said that this modification is always necessary when building with gcc, so it may not just be limited to the really old version I'm using. Since pepi37 was able to fix his issue by upgrading to a newer gcc, perhaps the behavior has since been changed; though it seems versions with the older behavior are still quite prevalent.

If it doesn't interfere with other (non-gcc) compilers, it might be helpful to include the -D__STDC_FORMAT_MACROS flag in the official source code (both for the sr*sieve projects, and for PRPnet, which also has this issue).

[QUOTE=lalera;408233]haswell - [url]https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29[/url][/QUOTE]

4670 at 3.4 GHz :smile:

[QUOTE=KEP;408279]4670 at 3.4 GHz :smile:[/QUOTE]

Now, if you'd just learn to spell "haswell", we'd all be in agreement.

[QUOTE=VBCurtis;408319]Now, if you'd just learn to spell "haswell", we'd all be in agreement.[/QUOTE]

Okay it is a Haswell:wink: I5-4670 @ 3.4GHz :smile:

If anyone would like to start up some base 3 work, please use the attached srbsieve.ini file.

Remember to change following:

mink=
maxk=

and set c= accordingly to the side you are searching (1 for sierpinski side and -1 for the riesel side)

I do recommend, for base 3 that you sieve with NewPGen* to these n:

From n=1 to n=28 if you sieve and test a range of 1G
From n=1 to n=30 if you sieve and test a range of 2G
From n=1 to n=32 if you sieve and test a range of 4G

* [B]REMEMBER TO SIEVE EACH n[/B], from p=1 until NewPGen [B]TERMINATES BY ITSELF[/B] else you will have composites in your primelist.

If you sieve to only n=28, remove following lines from the srbsieve.ini file:

npgfile=29,29_.log
npgfile=30,30_.log
npgfile=31,31_.log
npgfile=32,32_.log

If you sieve to only n=30, remove following lines from the srbsieve.ini file:

npgfile=31,31_.log
npgfile=32,32_.log

If you sieve to n=32, after having changed what you are noticed to change in the beginning of this post, leave everything else untouched.

Now if we could get 16 cores with the equivalent force of an I5-4670 @ 3.4GHz running base 3, we should be able to have the entire base 3 tested to n=25K before the end of this year, as long as people use the optimized ini file, attached to this post.

Anyone care to join the effort and help getting base 3 completely started? PuzzlePeter would you? :smile:

I may as well jump in here.
I'm trying S3 from 1G to 1.1G

Got my newpgen files to n=23

Have latest pfgw 3.7.10
Have srsieve
Have srbsieve dated 8/15/15

SRBsieve started and removed from all 23 files
I then got the message

Started recovery at Phase 0 with 4247788 terms
ERROR m 1e10: argument out of range

My ini file looks like:

base=3
mink=1000000001
maxk=1100000000
c=1
npgfile=1,n1.log
npgfile=2,n2.log
npgfile=3,n3.log
npgfile=4,n4.log
npgfile=5,n5.log
npgfile=6,n6.log
npgfile=7,n7.log
npgfile=8,n8.log
npgfile=9,n9.log
npgfile=10,n10.log
npgfile=11,n11.log
npgfile=12,n12.log
npgfile=13,n13.log
npgfile=14,n14.log
npgfile=15,n15.log
npgfile=16,n16.log
npgfile=17,n17.log
npgfile=18,n18.log
npgfile=19,n19.log
npgfile=20,n20.log
npgfile=21,n21.log
npgfile=22,n22.log
npgfile=23,n23.log
phase=100,33000,70000
phase=335,33000,140000
phase=674,33000,315000
phase=898,33000,552500
phase=1120,33000,425000
phase=1792,33000,977500
phase=2240,33000,595000
phase=2636,33000,1080000
phase=3512,33000,2790000
phase=4364,33000,4410000
phase=5205,33000,4950000
phase=6948,33000,10620000
phase=8624,33000,18000000
phase=10288,33000,31410000
phase=13703,20000,91800000
phase=17027,15000,154800000
phase=20310,15000,190224368
phase=25000,10000,360000000

???

Random question, but shouldn't [CODE]kBitMap = (uint8_t *) malloc((size_t) 1 + (maxK - minK + 1 / 8));[/CODE]
be
[CODE]kBitMap = (uint8_t *) malloc((size_t) 1 + ([B][SIZE="4"]([/SIZE][/B]maxK - minK + 1[B][SIZE="4"])[/SIZE][/B] / 8));[/CODE]

It hasn't caused any issues so far that I've seen, so maybe it doesn't matter, but I just wanted to make sure.