[QUOTE=Xentar;93031]"3450 3500" (with space) works fine.[/QUOTE]
[3450-3500 doesn't work]

As far as I can tell this is due to a bug in the mingw32 fscanf() function, I'll try to find a work-around for the next version.

[QUOTE=Xentar;93031]Think it doesnt work?

3450-3500

ERROR: Malformed first line in `sr5work.txt'.
[/QUOTE]
This is fixed in version 1.4.7, it was my mistake not a bug in mingw32.

What does it mean when you are in the proper directory, have the sieve file, have a file with the ranges, and ./sr5sieve gets you "bash: ./sr5sieve: No such file or directory" The file IS there, but the computer doesn't want to run it.

I got the same result with the ecm client. I'm a total linux noob, so it may be a simple error.

[QUOTE=jasong;93230]What does it mean when you are in the proper directory, have the sieve file, have a file with the ranges, and ./sr5sieve gets you "bash: ./sr5sieve: No such file or directory" The file IS there, but the computer doesn't want to run it.
[/QUOTE]
It probably means your permissions for the directory or the files in it are wrong. What does `ls -la' report?

[QUOTE=geoff;93348]It probably means your permissions for the directory or the files in it are wrong. What does `ls -la' report?[/QUOTE]
I'm not sure what you're asking for, so I'll type the line of output for sr5sieve.

[code]drwxr-xr-x 2 jasong jasong 4096 2006-12-04 17:25 sr5sieve[/code]

[QUOTE=jasong;93466][code]drwxr-xr-x 2 jasong jasong 4096 2006-12-04 17:25 sr5sieve[/code][/QUOTE]
OK, that is a _directory_ called sr5sieve. For `./sr5sieve' to work you need the sr5sieve _executable_ to be in the current directory.

sr5sieve 1.4.8
 

`sr5sieve -a K N0 N1' will create an ABC file for sequence K*5^n+/-1 called K.txt with all the terms N0 <= n <= N1 from sr5data.txt. (For use as input to Phrot).

Whatever mistake I made before, it is now working.

I dunno.

There are some binaries optimised for athlon, pentium-m etc. in the sr5sieve/arch directory. (There is no difference between versions 1.4.8 and 1.4.9 for these machines).

I doubt they will be much faster than the i686 binary, but they are there for comparison if anyone wants to try them out.

[QUOTE=geoff;93775]
I doubt they will be much faster than the i686 binary, but they are there for comparison if anyone wants to try them out.[/QUOTE]

Indeed, none are faster on an Athlon-64 X2
(at least not noticeable on a few minutes run)

[QUOTE=jasong;93571]Whatever mistake I made before, it is now working.
[/QUOTE]

Are you running 64-bit Linux? If so it would be a great help if you could try out the linux64-k8 binary and see how speed compares to the linux32-i686 binary on the same machine.