Msieve v1.48 feedback

[jasonp]

When the input has three factors it definitely is silly to not give any hint about what's happening, especially when each square root takes hours to run. Also, for large enough NFS problems, when a cofactor is composite but under about 100 digits, it might make more sense to just run QS on it immediately rather than wait for another dependency :)

Fixing that is in my queue.

[jasonp]

Okay, this is added in the latest SVN. I've also added the ability to set TARGET_DENSITY from the command line, using a new '-D' option to the demo binary. Give it a try to make sure it works; this will hopefully remove the need to compile a custom msieve version for a lot of people here.

[Random Poster]

Originally Posted by xilman

In principle, I guess that both factors could be composite and further iterations are need to split them both but I've never seen it happen.

There's a reason for that: if a number is small enough to be factored by NFS, and all of its prime factors are too large to be found by ECM in a fraction of the NFS runtime, then it's unlikely that there are more than three of them.

[Random Poster]

Originally Posted by jasonp

Also, for large enough NFS problems, when a cofactor is composite but under about 100 digits, it might make more sense to just run QS on it immediately rather than wait for another dependency :)

Or you could just print a warning about insufficient ECM and let the user wait; a few hours won't make any difference after already wasting days (or even weeks).

[xilman]

Originally Posted by Random Poster

There's a reason for that: if a number is small enough to be factored by NFS, and all of its prime factors are too large to be found by ECM in a fraction of the NFS runtime, then it's unlikely that there are more than three of them.

Sure, unlikely but possible. Consider a c260 by SNFS. There could be four p65 hiding in there but it's unlikely. It's quite likely that not a single factor would be found even after a significant amount of ECM work.

Paul

[xilman]

Originally Posted by Random Poster

Or you could just print a warning about insufficient ECM and let the user wait; a few hours won't make any difference after already wasting days (or even weeks).

A C150 by GNFS could easily run into this scenario. Suppose C150 = p48*p48*p54 --- quite easy for the two p48 to have been missed by ECM pre-testing.


Paul

[em99010pepe]

Just lost three hours of post-processing with the following error. Don't know what happened.

Tue Mar 22 04:57:13 2011  linear algebra at 0.0%, ETA 228h48m
Tue Mar 22 04:57:49 2011  checkpointing every 50000 dimensions
Wed Mar 23 15:23:58 2011  error: corrupt state, please restart from checkpoint
Wed Mar 23 18:15:05 2011  
Wed Mar 23 18:15:05 2011  
Wed Mar 23 18:15:05 2011  Msieve v. 1.48
Wed Mar 23 18:15:05 2011  random seeds: 6176cf00 8b977520
Wed Mar 23 18:15:05 2011  factoring

[jasonp]

Did the restart happen successfully? Serge did have problems with random LA failures when his computer got hot in the California summer...

[Batalov]

I was about to (re-)remind Jason to categorize msieve-reported errors into errors and (alleged) hardware errors. This one is one of the latter.

This is not an error of the code, in other words. With ECC memory, afaik, it was never reported, ever. And never in California winter! ;-)
__________

...and in summer, too, I am ever grateful to whatever happens. Cf. to Socrates: "By all means marry. If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher...and that is a good thing for any man."

[em99010pepe]

Originally Posted by jasonp

Did the restart happen successfully? Serge did have problems with random LA failures when his computer got hot in the California summer...

Manually yes.

[jasonp]

OK, keep us posted.

--
"I drank what?" --Socrates