mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   YAFU (https://www.mersenneforum.org/forumdisplay.php?f=96)
-   -   Yafu (https://www.mersenneforum.org/showthread.php?t=10871)

debrouxl 2012-01-10 08:12

SIQS on a C114 should take quite a bit of time, certainly days. GNFS usually becomes more efficient than SIQS around C100 +/- 5 digits or so.

LaurV 2012-01-10 10:14

[QUOTE=Jeff Gilchrist;285586]Quick and hopefully simple question.

Is there a way to get YAFU to print out the current status of completing a SIQS to stdout? Right now it shows the ecm # current/# total curves while doing factor() and when SIQS sieving starts it shows the number of relations needed but it doesn't show the current progress.

I have tried using:
v=1

In the yafu.ini file which gives more information but does not print out the sieving progress. Is there anything I can put in the .ini file to do this?

Thanks.[/QUOTE]
This is not from yafu, but from perl, is that is called "buffered output" and I tried to go around it in the past using sysxxx functions in perl, but it is quite difficult. See the discussion in the FactorDB thread, starting from [URL="http://www.mersenneforum.org/showpost.php?p=270947&postcount=1224"]post 1224[/URL] (and some related posts before). I think the best solution to it would be an option in yafu to send a CR/LF after the last CTRL+B that is sent for partial outputs. This would be very easy to "parse out" in perl and it will not generate additional lines on screen. There is also possible to parse the yafu output char-by-char but that is painful in perl...

edit: sorry, did not see the discussion after, please ignore my post. The idea with an optional CTRL+M after the series of CTRL+B still stands, if bsquared wants to implement it.

edit 2: @ciocker: you have to install ggnfs as explained [URL="http://gilchrist.ca/jeff/factoring/index.html"]here[/URL] and/or modify the path to it in yafu.ini

bsquared 2012-01-10 14:19

[QUOTE=c10ck3r;285663]My question is: How long/how many times is this expected to go on. I'm using a P4 3.2GHz cpu to run it and its doing about 4.5 rels/sec. Thanks in advance![/QUOTE]

According to some rough extrapolations, you'll need somewhere in the neighborhood of 4 million relations for a C114 with SIQS. At 4.5 rels/sec, that makes it about 10 days. I'd expect less than half that using GNFS, but even with GNFS it will likely still take a couple days. P4's are notoriously poor sievers.

[QUOTE=LaurV;285696] The idea with an optional CTRL+M after the series of CTRL+B still stands, if bsquared wants to implement it.
[/QUOTE]

It would be fairly easy to implement, but yoyo already has his script and it might be more work for him to rewrite it than it would be for me to modify yafu. It's great that folks are using yafu in a variety of scripts , but it does make one a bit more cautious in changing the interface.

EdH 2012-01-10 14:21

Several of my machines that are running yoyo's script have stopped with the message "matrix exhausted."

machine 1:
[code]
get composites
Factoring 92 digits: 13241186151397050176427910839378077439437378269478281521444173295151106131607035705221537083


factoring 13241186151397050176427910839378077439437378269478281521444173295151106131607035705221537083

div: primes less than 10000
matrix exhausted
[/code]machine 5:
[code]
get composites
Factoring 88 digits: 1133425551508756227542152854668512635199333667691612452626783181182419703714818195240521


factoring 1133425551508756227542152854668512635199333667691612452626783181182419703714818195240521

div: primes less than 10000
matrix exhausted
[/code]machine 9:
[code]
get composites
Factoring 90 digits: 843474189075746102648216901864992205423591606975292362913823714706860943979311076357949101


factoring 843474189075746102648216901864992205423591606975292362913823714706860943979311076357949101

div: primes less than 10000

starting SIQS on c42: 280857576802235430132495860755517200701211

==== sieving in progress (1 thread): 656 relations needed ====
==== Press ctrl-c to abort and save state ====
626 rels found: 302 full + 324 from 2550 partial, (1536.71 rels/sec)

SIQS elapsed time = 2.9698 seconds.
matrix exhausted
matrix exhausted
[/code]I had not previously seen this and I've run yoyo's script for more than a week continuously on these machines in the past. This failure was within a few hours from start and nothing I can think of has changed on these machines. The numbers are larger now than back then, but #5 was only working on a c88 and other nearly identical machines are running c9x numbers right now.

Thoughts?

bsquared 2012-01-10 14:29

[QUOTE=EdH;285719]Several of my machines that are running yoyo's script have stopped with the message "matrix exhausted."

Thoughts?[/QUOTE]

That message is from my old MPQS code that used a gaussian elimination routine I wrote instead of jasonp's block Lanczos routine. "matrix exhausted" happens sometimes when the GE matrix "fills in", and a solution can't be found. The routine was not very sophisticated...

I realize you are stuck using an old version of yafu because you have a 32 bit linux distro (fix that!). The upcoming new release of yafu should compile on 32 bit linux, so hopefully soon you will be able to upgrade.

EdH 2012-01-10 14:41

[QUOTE=bsquared;285720]That message is from my old MPQS code that used a gaussian elimination routine I wrote instead of jasonp's block Lanczos routine. "matrix exhausted" happens sometimes when the GE matrix "fills in", and a solution can't be found. The routine was not very sophisticated...

I realize you are stuck using an old version of yafu because you have a 32 bit linux distro (fix that!). The upcoming new release of yafu should compile on 32 bit linux, so hopefully soon you will be able to upgrade.[/QUOTE]
Thanks! My "steam-driven" machines are what I have. Unfortunately, I have one AMD machine that runs circles around these others, but it lacks SSE2, so I can't run YAFU at all on that one.:sad:

It wouldn't be as bad, if the program would break loose and go to another number instead of just stopping. But, I have enough other interests to put these to work elsewhere.

Looking forward to your new release...

LaurV 2012-01-10 14:51

[QUOTE=bsquared;285718]It would be fairly easy to implement, but yoyo already has his script and it might be more work for him to rewrite it than it would be for me to modify yafu. It's great that folks are using yafu in a variety of scripts , but it does make one a bit more cautious in changing the interface.[/QUOTE]
Assuming there is an option switch on yafu cmd line and/or yafu ini to print a newline character after every series of ctrl+b (or \b, whatever you call it), it would take for me a minute to modify yoyo's script to ignore the newline if it comes after a \b. For yoyo it would take 5 seconds.

edit: so, this option would target exactly the situation when yafu is run from yoyo's script (perl): running yafu without option, with or without yoyo script will be exactly as now. Running yafu standalone with option will produce more output (each partial message written on a new line, I don't know why someone would want that), and running yafu with option from yoyo script will look exactly as running yafu standalone without option (that is, partial outputs would appear on the same line).

bsquared 2012-01-11 17:39

version 1.30 available
 
Fixes a few bugs/issues (decimal digit size), adds some usability enhancements to nfs (skipping the search for the last special-q if all one wants to do is sieve, etc), incorporates code contributed by Warren Smith which implements an optimized version of Lehman's factoring algorithm (useful for really small inputs), adds some new logging info (to screen and file), and should now compile with 32 bit linux, 32 bit mingw, and on mac OSX.

But the big change is a fundamental overhaul of the workhorse factor() routine. I did away with the timing based pretesting method that tended to do funny stuff like run one curve at 1B and instead implemented a state machine using "t-levels". I don't know fur sure if it is universally accepted terminology or not, but enough people around here use it that I think it is understood what is going on. I[FONT=Courier New][FONT=Verdana]t is a handy way to talk about [/FONT][/FONT][FONT=Courier New][FONT=Verdana][SIZE=2]how much a particular number has been tested with ecm.[/SIZE][/FONT][/FONT]

Bascially, [FONT=Courier New][FONT=Verdana]Something that has [/FONT][/FONT][FONT=Courier New][FONT=Verdana]received, say, "t30", has had enough ecm curves run on it so that the probability [/FONT][/FONT][FONT=Courier New][FONT=Verdana]that a factor of size 30 has been missed is exp(-1) (about 37%). Likewise, [/FONT][/FONT][FONT=Courier New][FONT=Verdana]t35 indicates that factors of size 35 are expected to be missed about 37% [/FONT][/FONT][FONT=Courier New][FONT=Verdana]of the time (at which point a 30 digit factor would only be expected to be [/FONT][/FONT][FONT=Courier New][FONT=Verdana]missed ~5% of the time). The t-levels are calculated from tabulated data that was extracted [/FONT][/FONT][FONT=Courier New][FONT=Verdana][SIZE=2]by A. Schindel from GMP-ECM in verbose mode.[/SIZE][/FONT] [/FONT]

[FONT=Courier New][FONT=Verdana][SIZE=2]YAFU's factor() routine will now test an input to a certain t-level (depending on the specified -plan option) before proceeding to qs or nfs. The following plans (and their default t-level) are supported (similar to before):[/SIZE][/FONT][/FONT]

[FONT=Courier New][FONT=Verdana][SIZE=2]-plan light (2/7 * size of input in decimal digits)[/SIZE][/FONT][/FONT]
[FONT=Courier New][FONT=Verdana][SIZE=2]-plan normal (4/13 * size of input in decimal digits)[/SIZE][/FONT][/FONT]
[FONT=Courier New][FONT=Verdana][SIZE=2]-plan deep (1/3 * size of input in decimal digits)[/SIZE][/FONT][/FONT]
[FONT=Courier New][FONT=Verdana][SIZE=2]-plan custom (size of input in decimal digits * value specified in -pretest_ratio option)[/SIZE][/FONT][/FONT]

[FONT=Courier New][FONT=Verdana][SIZE=2]As before, after pretesting with ecm/pp1/pm1 is done, either qs or nfs is run depending on the crossover computed from running tune(). If tune has not been run, the default is 95 digits. Regardless of tune(), the new option -xover <num> will force the crossover to nfs beyond the specified number of digits.[/SIZE][/FONT][/FONT]

[FONT=Courier New][FONT=Verdana][SIZE=2]Finally, the new option -work <num> allows one to tell YAFU that an input has already received ecm equivalent to the specified t-level. factor() will then pick up pretesting in the appropriate place. For example, if you know that a number has already received 900 curves at B1=1M, then call factor() with -work 35 and it will start ecm with B1=3M curves. This does require you to be able to translate completed ecm curves into an equivalent t-level, but most power users of YAFU probably know how to do that. The GMP-ECM README file will help, if not. And for general use, factor() is still fire-n-forget, no knowledge of t-levels is needed or required.[/SIZE][/FONT][/FONT]

[FONT=Courier New][FONT=Verdana][SIZE=2]I think this new methodology for factor() (along with the new options) better emulates how folks manually try to factor large inputs, and is much more flexible than the old method. As always, feel free to leave me feedback here or via email.[/SIZE][/FONT][/FONT]

- ben.

pinhodecarlos 2012-01-11 17:43

Thank you Ben!

firejuggler 2012-01-11 18:21

Thank you Ben!

debrouxl 2012-01-11 19:23

Great, thank you :smile:


All times are UTC. The time now is 22:31.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.