Is it possible to set -threads 2 in an .ini file? (This would be nice for factoring with aliqueit - as aliqueit.exe is not (yet?) able to call yafu with the "-threads x"-option.)

Factoring 70!-1, I have get:

P4 = 1823
PRP15 = 333434996390401
[B]C23[/B] = 11249076547278643747307
PRP61 = 1751823366233125592434934617123408693771754792700962263847459

Is that a bug?

[quote=mataje;190446]Factoring 70!-1, I have get:

P4 = 1823
PRP15 = 333434996390401
[B]C23[/B] = 11249076547278643747307
PRP61 = 1751823366233125592434934617123408693771754792700962263847459

Is that a bug?[/quote]

No, its a feature :smile:.

The C23 factors as

[CODE]PRP12 = 486676665551
PRP11 = 23114065957[/CODE]

which are both smooth to the default P-1 bounds. So they are both found at the same time by P-1. I don't have any procedure in place to split composites found in this way.

[QUOTE=bsquared;190391]:redface: I was wondering when someone was going to poke me on this, since it was supposed to be a quick job. I was hoping it could wait till I get 3LP implemented, and then maybe give SIQS a chance at a new record.[/QUOTE]

You should either do it, or release it so that someone else can.
AN SIQS record would be pointless.

[quote=R.D. Silverman;190454]You should either do it, or release it so that someone else can.
AN SIQS record would be pointless.[/quote]

I agree that a new QS record is pointless, but so is the factorization, right? It's just another stamp for the collection, so what's the hurry?

[QUOTE=bsquared;190456]I agree that a new QS record is pointless, but so is the factorization, right? It's just another stamp for the collection, so what's the hurry?[/QUOTE]

Dr Silverman is very Cunningham-oriented. He wants to see them finished ASAP. I agree that c149s that crop up in the Cunningham tables should be done quickly, but I think a QS record would be good (although not on a Cunningham number). Maybe take some near-repdigit or Homogeneous Cunningham?

[QUOTE=10metreh;190461] I think a QS record would be good (although not on a Cunningham number). [/QUOTE]


You miss the point.

It would be a waste of resources. Why take more time to do a
computation than necessary?

-- Answer: We take more time than necessary when we might learn
something. Exactly what would we learn from a QS record? We already
know how the algorithm works, how to optimize it, how to select its
parameters and how it performs.

Better to do the C149 via GNFS and utilize the extra resources required
by a QS record to do something else.

Setting a new record for an algorithm that is obsolete (for numbers of this
size) is POINTLESS.

[quote=R.D. Silverman;190475]You miss the point.

It would be a waste of resources. Why take more time to do a
computation than necessary?

-- Answer: We take more time than necessary when we might learn
something. Exactly what would we learn from a QS record? We already
know how the algorithm works, how to optimize it, how to select its
parameters and how it performs.
[/quote]

We'd learn nothing from a new record by itself, of course. But I'd learn quite a bit along the way. You and perhaps a few others on this earth know how to code the 3 large prime variation efficiently and pick optimal parameters, but I sure don't. I'm going to code it because I'd like to learn, and I'll need a few large test cases as I go. Probably the C149 is too big, but I wanted to set my sights high.

[QUOTE=bsquared;190495]We'd learn nothing from a new record by itself, of course. But I'd learn quite a bit along the way. You and perhaps a few others on this earth know how to code the 3 large prime variation efficiently and pick optimal parameters, but I sure don't. I'm going to code it because I'd like to learn, and I'll need a few large test cases as I go. Probably the C149 is too big, but I wanted to set my sights high.[/QUOTE]

I have a share of the sieving on Paul Leyland's current record for
three large primes, C135. But that wasn't a wanted number. Andi47's
just finished my other cofactor, C153; and this C149 cofactor was earlier,
from page 111; both listed by Sam as Smaller-but-Needed on the wanted
lists from page 112. If you're not planning on having it factored before
the close of page 112, you should give someone else a chance to.

-bdodson

PS - The C135 was set just in time to make the printing of the 3rd
edition. Appendix C at that time began with C130, C131, ... There
don't appear to have been Smaller-but-Needed numbers at that
time --- the wanted list is included with the 3rd edition --- but
the number we factored was well above the smallest unfactored
Cunningham. That's what this C149 is, and has been since it was
found. We take the smallest unfactored Cunningham as an indicator
of the current status of factoring. Aside from this one, the
unfactored numbers are C159, C160, C160, ... That's already a
nontrivial comparison; to match our record, you'd need to do a
C162-or-so. (And give-it-up, already!)

[quote=bdodson;190514]If you're not planning on having it factored before
the close of page 112, you should give someone else a chance to.

[/quote]

I misjudged the importance of the C149, sorry. There are plenty of other numbers out there for testing siqs; I've started poly selection.

[quote=Andi47;190444]Is it possible to set -threads 2 in an .ini file? (This would be nice for factoring with aliqueit - as aliqueit.exe is not (yet?) able to call yafu with the "-threads x"-option.)[/quote]

I've considered adding an .ini file to yafu before, but haven't done so yet. So sadly, no, this isn't possible right now.