[QUOTE=bchaffin;258905]I was under the impression that the python version of factMsieve was more widely used than the perl version, but maybe that's not the case. Is one of them considered more up-to-date than the other?

Anyway the python version seems to have a pretty good estimate of minimum relations; for most factorizations up to 130 digits I find that it usually runs filtering only once or twice. In fact that was my main reason for switching to it.[/QUOTE]The Python version appears to be more suitable for Windoze systems and the Perl version for Unix-like systems.

That said, the Python version running on my Win7 consistently underestimates the number of relations required. Perhaps I need to upgrade to a more recent version.

Paul

[QUOTE=xilman;258906]The Python version appears to be more suitable for Windoze systems and the Perl version for Unix-like systems.

That said, the Python version running on my Win7 consistently underestimates the number of relations required. Perhaps I need to upgrade to a more recent version.

Paul[/QUOTE]
I'm running the Python version on several WinXP (2) and Ubuntu (4) machines via Aliqueit and they rarely need extra relations, although almost all my work has been <110 digits. There was a lot of effort put into refining the estimated number a little while ago. The info can be found in [URL="http://www.mersenneforum.org/forumdisplay.php?f=83"]this[/URL] thread starting at around post #386. Perhaps it is an issue of not being up-to-date, but if it is still not sufficient, Brian Gladman should be let know in that thread.

[QUOTE=xilman;258887]Work around I discovered is to rename the foo.fb and foo.ini files out of the way. The filtering code then fails to run and the sieving continues.

When you think you really have enough relations, rename them back again.

Paul[/QUOTE]

The designed way is to set up a file called MINRELS.txt with a suitable number in it. factMsieve.pl will get at least that many relations before trying filtering.

Chris K

[QUOTE=chris2be8;258991]The designed way is to set up a file called MINRELS.txt with a suitable number in it. factMsieve.pl will get at least that many relations before trying filtering.

Chris K[/QUOTE]Ah, I didn't know that one. Thanks.

Paul

[QUOTE=bchaffin;258905]I was under the impression that the python version of factMsieve was more widely used than the perl version, but maybe that's not the case. Is one of them considered more up-to-date than the other?

Anyway the python version seems to have a pretty good estimate of minimum relations; for most factorizations up to 130 digits I find that it usually runs filtering only once or twice. In fact that was my main reason for switching to it.[/QUOTE]

I've been updating the perl version because I know perl but don't know python. I'll have a look at factmsieve.py to see if I can tell how it estimates minimum relations.

I'll be happy with a number near enough for msieve to estimate how many more it needs reasonably accurately.

Chris K

[QUOTE=jasonp;258870]That's unavoidable; you can't come up with a decent estimate of the remaining work to do, when singleton removal destroys the entire dataset. Any choice of answer at this stage will work, but the danger is that you will be working on a small problem and asking for much more than 1M relations will cause too much work to be done. Agreed that for a large job asking for 1M more relations means you'll be running the filtering once per day, uselessly for the first two weeks :)[/QUOTE]

Even a rough estimate would help. Eg the number of entries in the factor base, that scales with problem size so is less likely to ask for far to many relations.

Chris K

[QUOTE=EdH;258966]I'm running the Python version on several WinXP (2) and Ubuntu (4) machines via Aliqueit and they rarely need extra relations, although almost all my work has been <110 digits. There was a lot of effort put into refining the estimated number a little while ago. The info can be found in [URL="http://www.mersenneforum.org/forumdisplay.php?f=83"]this[/URL] thread starting at around post #386. Perhaps it is an issue of not being up-to-date, but if it is still not sufficient, Brian Gladman should be let know in that thread.[/QUOTE]

Yes, I'm happy to update the estimates it uses if people can provide better data or algorithms for making such estimates.

here is a few other that might help you, ranging from 85 to 118 digits

More relations.

15e, SVN413 x64: endless loop?
 

I just downloaded SVN 413 from Jeff's page. Is it intended, that the 15e binary says that it is SVN 406?

Edit: the 15e x64 binary seems to have entered an endless loop (or being otherwise extremely slow); I killed it after 15 minutes:

[code]gnfs-lasieve4I15e -v -M1 -a alq4788.2661.poly -o alq4788_test.out -f 16000000 -c 1000
gnfs-lasieve4I15e: L1_BITS=15, SVN $Revision: 406 $
Warning: lowering FB_bound to 15999999.
FBsize 1030098+0 (deg 5), 2063688+0 (deg 1)
total yield: 72, q=16000081 (8.10293 sec/rel) <-- 15 minutes after the run was started on an intel i7[/code]

[QUOTE=chris2be8;258991]The designed way is to set up a file called MINRELS.txt with a suitable number in it. factMsieve.pl will get at least that many relations before trying filtering.

Chris K[/QUOTE]

The issue I've been facing due to lack of knowledge on the subject is to understand how much raw relations are needed per SNFS job*. For SNFS difficulty of 180-182 and for any type of composite size at least 22-23M raw relations are needed to build a matrix. I really would like to understand this more accurate and not by test experience. Can someone point me to some papers regarding this matter?
In the attachment you will find my SNFS jobs done so far (excel spreadsheet). The file is my guide to estimate how many raw relations are needed.

* 2^LP/(LP ln(2)-1) always gives underestimated number of raw relations, where LP means large prime bits.

PS: xilman and wblipp have been helping me a lot. Thank you both!