[quote=lavalamp;129049]Just the other day I ended up losing quite a bit of time on a sieve when a program unexpectedly crashed and took the PC with it. I didn't know where the sieve was up to, so I had to simply start from the last found factor (though I am reasonably confident it had progressed quite a bit further, I had no way of knowing how much further).

Therefore would it be possible to include the same checkpoint feature that sr2sieve has in sr1sieve? I would very much appreciate it and thank-you for your time and all the work you have put into this so far.[/quote]
I think if you run sr1sieve with the -c option then you'll get a checkpoint file. :smile:

sr1sieve says that -c is an unknown option.

[quote=lavalamp;129071]sr1sieve says that -c is an unknown option.[/quote]
Oh, whoops, I guess I should have checked first. :blush:

Well, in the absense of a checkpoint feature, you might be interested in the -s option, which lets you change how often sr1sieve saves its output sieve file. For example, you could add the switch "-s 5" to your sr1sieve command line to have it save the sieve file every 5 minutes. Since sr1sieve only works with one k at a time, your sieve file will probably be very small, and thus sr1sieve will probably take no longer to save it than it would to save a checkpoint file. :smile:

For the range and depth that I'm currently sieving, the factors come few and far between, so outputting more often won't have any effect, I'll still be left with just the latest factor.

[quote=lavalamp;129075]For the range and depth that I'm currently sieving, the factors come few and far between, so outputting more often won't have any effect, I'll still be left with just the latest factor.[/quote]
sr1sieve will save the sieve depth information in the output file (it's the first number in the first line of a NewPGen format file such as the ones generated by sr1sieve), and you can easily resume from whatever depth is listed in the file by not specifying a pmin on the command line. :smile:

Ah, I see, well that could come in handy then. I didn't even realise that sr1sieve could work with NewPGen format files, I've been using srfile to strip factors from ABCD format files.

[quote=lavalamp;129082]Ah, I see, well that could come in handy then. I didn't even realise that sr1sieve could work with NewPGen format files, I've been using srfile to strip factors from ABCD format files.[/quote]
Yep, just use the -o option and sr1sieve will write directly to a NewPGen format file. :smile:

Very good indeed, I'll use the following from now on then:[code]sr1sieve -s 10 -i "sieve.txt" -o "sieve.txt" -f "factors.txt" -P <hooj>[/code]Thank-you for enlightening me. :smile:

[quote=lavalamp;129104]Very good indeed, I'll use the following from now on then:[code]sr1sieve -s 10 -i "sieve.txt" -o "sieve.txt" -f "factors.txt" -P <hooj>[/code]Thank-you for enlightening me. :smile:[/quote]
May I please inquite what "<hooj>" is supposed to mean? :smile:

[QUOTE=lavalamp;129049]\Therefore would it be possible to include the same checkpoint feature that sr2sieve has in sr1sieve? I would very much appreciate it and thank-you for your time and all the work you have put into this so far.[/QUOTE]

This is on my list of things to do, as it will be needed to use sr1sieve with BOINC too. In the meantime using the -o switch to write a save file that Anonymous gave works OK.

(I have become caught up with searching for GFN factors and so have been distracted from srsieve lately. If anyone is interested in this see [url]http://www.geocities.com/g_w_reynolds/gfn/[/url]).

[QUOTE=Anonymous;129109]May I please inquite what "<hooj>" is supposed to mean? :smile:[/QUOTE]hooj = huge, just funnier. Since numbers after -P do seem to be on the large side, though still no-where near the size of the numbers in the sieve.

Out of extreme, never ending, curiosity, how come there are four srsieves? They all seem to do quite similar things, though obviously they are optimised for particular areas, sr2sieve is more optimised for multiple ks whereas sr1sieve is optimised for a single k, but that could be dealt with using a simple if/else to call a one function or another.

I haven't read through the code, and would probably get my head spun around if I tried, so I imagine there are many reasons you could tell me to shut up for asking this but ... how come there's not just one program that has a module for input/output of the files (much like srfile), and then some logic that, based on the type of candidates to factor, chooses the appropriate sieve algorithm?

This isn't me being lazy and just wanting one program that I can blindly throw numbers at, I'm quite happy to continue [SPOILER]blindly throwing numbers at[/SPOILER] expertly using the seperate programs as they work very well. Like I said, I'm just far too curious for my own good.