[QUOTE=richs;204469]bbuhrow at gmail dot com[/QUOTE]

Could a mod break that email address?

Sorry, I didn't notice that the email address was in the screen output.

[QUOTE=10metreh;204483]Could a mod break that email address?[/QUOTE]Not only could, but did.

Paul

gmail has a pretty good spam filter, but thanks for fixing that Paul.


As for richs problem, is there any way a different instance of yafu could have stomped on the savefile, i.e., running another instance of yafu in the same directory?

The "bad poly A" message are printed when a polynomial in the save file contains a factor which is not in the factor base. So either a bunch of the data is corrupt or relations/polynomials from a different factorization somehow made their way into the savefile.

Sorry that the code isn't more robust to this issue... that's something I can and need to make better. but unfortunately I don't know of a good way around this other than starting over.

As an act of penance, I can factor that number fairly quickly for you if you want.

here you go:

[CODE]SIQS elapsed time = 974.2156 seconds.

***factors found***
PRP62 = 85049442632427611569298534865611331158732574750385577800252801
PRP33 = 104882813314736572133370673548191
[/CODE]

Thanks for the info. On that number, I had started YAFU and it ran for a while when I halted it due to power problems. I restarted and it picked up the relations from the initial save file, discarding a number of them. As you noted, something was corrupted during this process.

Anyway, I left YAFU re-running the number last night and it took 8.35 hours to successfully complete. You obviously have much more computing resources than me! Anyway, no penance was necessary, and I appreciate the use of your program.

Rich

[quote=richs;204571]

Anyway, I left YAFU re-running the number last night and it took 8.35 hours to successfully complete. You obviously have much more computing resources than me! Anyway, no penance was necessary, and I appreciate the use of your program.

Rich[/quote]

I'm glad it completed sucessfully for you, thanks for the feedback. I haven't had much time to work on yafu lately, but I'll put some more error handling in the next version so that the program at least won't crash when encountering this problem.

P.S.
We just recently got some new hardware where I work; the factorization I posted was done with an 8 core xeon workstation. I actually tried it twice; the second time 16 threaded on a new i7 based xeon workstation. It took ~ 10 min to complete :smile:.

[QUOTE=richs;204571]Anyway, I left YAFU re-running the number last night and it took 8.35 hours to successfully complete. [/QUOTE]

Get GGNFS. It's faster at 94 digits. :smile:

What is the approximate composite size where it becomes faster to use GGNFS? Thanks!

[quote=richs;204678]What is the approximate composite size where it becomes faster to use GGNFS? Thanks![/quote]
With the latest version of GGNFS (including the gnfs-lasieve4I11e siever), it's around 85 digits, though the 85-90 range is somewhat borderline.

[QUOTE=10metreh;204580]Get GGNFS. It's faster at 94 digits. :smile:[/QUOTE]

The version of factMsieve.pl I have is probably old. It doesn't know about msieve degree 4 poly selection or gnfs-lasieve4I11e. Is there such a version of factMsieve.pl?