76M - 77M to 2^60

[cheesehead]

Mr. P-1,

Some parts of your posting propose a revision in the way P-1 and TF are performed, including changes to the algorithms for choosing TF and P-1 B1/B2 limits and changes to the order in which TF and P-1 are performed.

At other points, you seem to be writing about the current status of the operation of the PFactor command.

I think there needs to be a clear separation of those two discussions.

Your argument about the proper setting of the "bits" field in the command lines for PFactor, Test, DoubleCheck, and Factor make senses in the context of your proposed future alteration of the way the factoring is integrated. But as a statement about the current operation of PFactor, et al., it confuses the order in which certain events occur and certain probabilities are calculated.

At one point, you agree with me that

Originally Posted by cheesehead

the "bits" field of "Pfactor" lines means the same thing as the "bits" field in "Test" and "DoubleCheck" lines, namely the number of bits to which the number has already been trial-factored.

Originally Posted by Mr. P-1

Ditto.

So we agreed that the "bits" parameter on the Test, DoubleCheck, and PFactor command lines is supposed to be the number of bits (or, more accurately, the power of two) to which the number has already been trial-factored.

That fits in the context of current, present-day operation.

But later in your posting you write,

Originally Posted by Mr. P-1

But this is only true if the factor is longer than the maximum depth to which the exponent will be factored. If a factor smaller than this is found, then all that is saved is the extra time taken to TF to that factor.

Here you are thinking of your proposed future scheme, not the current situation.

Will you please make a clear separation so as not to confuse the reader about present-day parameter settings?

Originally Posted by Mr. P-1

In the mean time, I'm reluctant to recommend setting the 'bits' parameter to more than the 'will do to' level, but it certainly shouldn't be set lower.

Please make it clear that this refers to your future proposal, not current settings.

[lycorn]

Boulder, markr and garo

This is just to warn you guys that the 14 33.6M exponents factored to 64 bits by markr, that boulder is supposed to have already started TFing to 68 bits, are currently on the mersenne.org/range2 page, available for anyone to get them for manual testing. In order to avoid duplicated work, you could perhaps ask George to remove them from there, until they are finished to 68 bits...

[Boulder]

I'll email George and tell him that I'll TF those markr's exponents to 2^68.

EDIT: Email sent. I also added the rest of the exponents to the worktodo.ini file. It might take quite a while to factor all of them but they'll come out eventually. I'm able to run the computer more in the summertime so things will speed up a bit.

[trif]

Whoops, forgot about checking the "completely manual, email George" type testing page.

[Boulder]

He he, the whole LMH project will soon have to be included in the databases..way too many places to check before doing anything :D

[trif]

Hopefully the new Primenet will be able to accomodate LMH type activity, so we won't have to have such an ad hoc arrangement any more.

[Primenut]

Any word on the time table to the new Primenet? So as for LMH work one could check out a range and do it bit wise rather than the current factoring up to the default bit?

[Mr. P-1]

Originally Posted by cheesehead

Mr. P-1,

Some parts of your posting propose a revision in the way P-1 and TF are performed, including changes to the algorithms for choosing TF and P-1 B1/B2 limits and changes to the order in which TF and P-1 are performed.

At other points, you seem to be writing about the current status of the operation of the PFactor command.

At all times, I have been writing about the current status. I'm proposing an optimisation that can be done now, using the existing software. However, to justify my claims, I have used hypothetical revisions to illustrate my arguments. If I have failed sufficiently to distinguish between these gedankenexperimenten and the practical proposal, then I apologise.

I think there needs to be a clear separation of those two discussions.

Your argument about the proper setting of the "bits" field in the command lines for PFactor, Test, DoubleCheck, and Factor make senses in the context of your proposed future alteration of the way the factoring is integrated. But as a statement about the current operation of PFactor, et al., it confuses the order in which certain events occur and certain probabilities are calculated.

I am proposing that the order be changed, in which these events occur. Boulder could do this, today, with his current client, if he so wishes.

[quote]At one point, you agree with me that

Originally Posted by cheesehead

the "bits" field of "Pfactor" lines means the same thing as the "bits" field in "Test" and "DoubleCheck" lines, namely the number of bits to which the number has already been trial-factored.

Originally Posted by Mr. P-1

Ditto.

I beg your pardon. By 'ditto', I was refering to my earlier remark:-

Originally Posted by Mr. P-1

That's what it says. The tacit assumption, however, is that P-1 is done after TF is complete, so the two values are the same. The relevent question is not 'what does the parameter mean?', but 'what is the optimal value to give it?'

I apologise for not making this clear.

So we agreed that the "bits" parameter on the Test, DoubleCheck, and PFactor command lines is supposed to be the number of bits (or, more accurately, the power of two) to which the number has already been trial-factored.

Actually I do agree with this, however you're mixing up several different questions, which need to be separated:

1. What does this parameter mean?

2. What is this parameter supposed to be?

3. What value should Boulder use for this parameter, assuming he agrees to my plan, if he wishes to optimise his contribution to the project?

1 is a metaphysical question which I will leave to the philosophers. 2 can be construed as a question about George's intentions when he concieved, programmed and wrote up the parameter. I do not dispute that it is supposed to be the number of bits factored so far.

3, however, is an entirely different question, with a different answer. This is the only question I was addressing in my original post.

That fits in the context of current, present-day operation.

But later in your posting you write,

Here you are thinking of your proposed future scheme, not the current situation.

No, I am thinking about what I am proposing Boulder (and perhaps others) do now. Specifically, that someone else TFs 33.8M exponents up to 65 bits (say), Boulder then does the P-1, and finally someone else completes the survivors up to 67 bits.

My claim is that if Boulder does this, then he should set this parameter to 67, even though it is 'supposed' to be 65. I also attempted to justify this claim.

I fully concede that I may not have explained this justification clearly, or properly separated it from the other parts of my argument. If you are still not clear, but sufficiently interested, I'd be willing to give it another try. :)

Regards

Daran

[cheesehead]

Originally Posted by Mr. P-1

I beg your pardon. By 'ditto', I was refering to my earlier remark:

You're right. You did not agree with me there. I apologize. Somehow I failed to realize the proper meaning of 'ditto' in that context. (* My subconscious says, "I _told_ you that you were overlooking something." *)

Originally Posted by Mr. P-1

Actually I do agree with this, however you're mixing up several different questions, which need to be separated:

Perhaps instead of "... is supposed to be the number of bits ...", I should have written something like "... is used by the current released version of Prime95 as the number of bits ...".

[markr]

Originally Posted by trif

Whoops, forgot about checking the "completely manual, email George" type testing page.

Whoops from me too. I see George has pulled the 14 exponents that I posted here & Boulder has taken. In the meantime, about half the remaining exponents from the "completely manual" page are now done to 2^64. Ah well...

I'll remove the remaining 3360xxxx exponents from the worktodo files tonight, to stay clear of the manual range. (I knew I should have checked the forum last night instead of cooking dinner. I'm sure the family would have understood. :) )

[garo]

Might wanna tell george about the ones that you have finished to 64. He will change the bits on the manual tests page.