[QUOTE=Citrix;92724]I was trying to sieve
[/QUOTE][some sequences with very large k][QUOTE]
from the 15 k low weight project from 1-2 million, the srsieve for windows just freezes, it does not start working for 15 mins or so, no factor output etc. Is this a bug?
[/QUOTE]

Before sieving can start the factors of each k are found by trial division. The trial division function I use just divides by each odd number up to sqrt(k), which for k < 2^32 was fine. When I extended the code to allow for k up to 2^64 I should have improved this trial division function :-)

I think it is just stuck in the trial division loop. Sorry about that. I'll try to write a better trial division function for the next version.

edit: As a work-around until then, try using the --no-filter switch. Sieving will be about one third slower, but I think it will avoid the need to do trial division. I haven't checked this though.

[QUOTE=geoff;92726]michaf requested this feature earlier. The file will be large, about 20MB, but it should be faster to load than recomputing the tables each time.[/QUOTE]

If the bitmaps are dumped as is (binary), would that reduce the file size (as well as the read and parse times)?

srsieve 0.6.1
 

[QUOTE=Citrix;92724]from the 15 k low weight project from 1-2 million, the srsieve for windows just freezes, it does not start working for 15 mins or so, no factor output etc. Is this a bug?
[/QUOTE]
This bug is fixed in srsieve 0.6.1.

sr5sieve 1.4.4
 

This version includes the PPC/Linux assembler powmod fix. It also prints an estimate of the number of factors expected to be found for the range.

[QUOTE=michaf]Geoff, can you make it happen, in a future release,
that sr5sieve will also accept work of the form:
3000-3050
[/QUOTE]
In this version you can use a comma, dash, space or tab to seperate the range start and end.

[QUOTE=axn1]If the bitmaps are dumped as is (binary), would that reduce the file size (as well as the read and parse times)?[/QUOTE]
20MB is the binary size (but it is getting smaller as primes are found. The large squarefree k with odd n need the largest bitmaps).

Hi, I am having a strange problem with the file [url]www.geocities.com/g_w_reynolds/sr5sieve/sr5sieve-1.4.4.tar.gz[/url] I can open my local copy with 7-zip no problem, but when I download a copy from yahoo 7-zip says the CRC is wrong and can't open it. I have uploaded the good file several times, and each time it comes back corrupt.

Could someone try downloading the file and see you can open it? Any ideas what is happening here?

Thanks for the updated version.

TO answer your question, Geocities server adds some code to the end of your file, so it does not open. The server thinks your file is a webpage, if you try to d/l it from the link in your post.

:smile:

I can download it fine,
It opens in winRar,
It shows 18 filenames (total 88241 bytes)
Those 18 files, I can read with winRar just fine, and are extracted too.
The archive tests as being corrupted:

! C:\Documents and Settings\MICHA\Local Settings\Temp\sr5sieve-1.4.4.tar.gz: CRC failed in C:\Documents and Settings\MICHA\Local Settings\Temp\sr5sieve-1.4.4.tar.gz. The file is corrupt

The files I am able to extract are:
arithmetic.c
arithmetic.h
bitmap.c
bitmap.h
bsgs.c
CHANGES
choose.c
clock.c
config.h
COPYING
events.c
factors.c
files.c
INSTALL
Makefile
README
README2
TODO

hope this helps...

[QUOTE=Citrix;92946]TO answer your question, Geocities server adds some code to the end of your file, so it does not open. The server thinks your file is a webpage, if you try to d/l it from the link in your post.
[/QUOTE]
It is strange that sr5sieve-1.4.5.tar.gz downloads OK, but sr5sieve-1.4.4.tar.gz still shows as corrupt. I didn't think junk at the end of the file would matter, it should get burnt off by gzip before the tar is opened, but 7-zip didn't complain about the .gz, only about the .tar inside.

Maybe 1.4.4 was corrupt before I uploaded it, I am transfering via floppy so it is not too unlikely, just strange that 7-zip didn't complain until after it had gone through yahoo.

sr5sieve-1.4.5 fix another bitmap related bug that caused 64-bit builds to incorrectly discard half of the factors as duplicates. It didn't affect the 32-bit builds so I haven't updated the 32-bit binaries.

[QUOTE=michaf;92996]IIt opens in winRar,
It shows 18 filenames (total 88241 bytes)
[/QUOTE]
Thanks, there are some files missing there. Hopefully sr5sieve-1.4.5.tar.gz will be OK if not downloaded via a link.

[QUOTE=geoff;92841]In this version you can use a comma, dash, space or tab to seperate the range start and end.[/QUOTE]

Think it doesnt work?

[QUOTE=sr5work.txt]3450-3500[/QUOTE]

[QUOTE=sr5sieve.exe]sr5sieve 1.4.4 -- A sieve for the Sierpinski/Riesel Base 5 projects.
Read 5404572 terms for 259 sequences from ABCD format file `sr5data.txt'.
Split 259 base 5 sequences into 4934 base 5^180 subsequences.
Reading project work file `sr5work.txt' ...
ERROR: Malformed first line in `sr5work.txt'.[/QUOTE]

Edit:
"3450 3500" (with space) works fine.

sr5sieve 1.4.6
 

sr5sieve version 1.4.6 will load the Legendre symbol tables from a cache
file `sr5cache.bin' if one is present in the current directory at startup.

To create the cache file, run `sr5sieve -c'. It is not necessary to create a
new file each time a new sr5data.txt is downloaded, as the cached tables
don't change and only the ones actually needed will be loaded.

sr5cache.bin is in an architecture-specific binary format, so it can't be
shared between 32- and 64-bit or big- and little-endian machines. (sr5sieve
will warn that the format is wrong and refuse to use the file if you try).

sr5cache.bin is also quite large (~18Mb with the 262 k sr5data.txt), so if
disk space becomes tight you can just delete it, sr5sieve will then build
the necessary tables from scratch at startup, as previous versions did.