Cooperative Agreement or Capitalist Takeover? You decide!

[Dubslow]

Originally Posted by chalsall

We've also found that the software provided by GIMPS did not always find the factors which should have been found....

In the case of recent versions of the last 1-2 years, this isn't true, and we know this because they [i]are[/i] finding factors that were missed the first time. For the times when the exponents were first P-1ed, yes, we can't prove that the program was correct. (I still think hardware errors are a much more likely culprit.)

Let me redo this ^. http://mersenne-aries.sili.net/p1mis...?s=x&o=a&p=200

There are exponents all the way up to 50M that have been missed. I'm pretty darn sure that since we are finding these on a second run, the hardware must have been to blame the first time.

[Prime95]

Originally Posted by Dubslow

There are exponents all the way up to 50M that have been missed. I'm pretty darn sure that since we are finding these on a second run, the hardware must have been to blame the first time.

Some versions of prime95 had TF bugs -- especially in the early days.

[Prime95]

Originally Posted by bloodIce

They have two factors for small exponents on their webpage (http://mersenneathome.net/), which are not in the GIMPS database:

How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?

If you do not hear back from mersenneathome as to their preference, then please create a GIMPS account called MersenneAtHome and submit the factors under that user id.

No one "owns" Mersenne factors, but they should be submitted with the proper credit.

I've not yet heard back from Bobrecki either by PM or email.

[markr]

Originally Posted by Dubslow

We've found that if bad hardware is used, sometimes factors are missed, when they should have been found.

Originally Posted by chalsall

We've also found that the software provided by GIMPS did not always find the factors which should have been found....

Originally Posted by Prime95

Some versions of prime95 had TF bugs -- especially in the early days.

Human error is also a likely cause of missed factors.

Errors likely happened in manipulating worktodo files, and TF results lines from early versions of the client did not show the starting level, so it was hard to pick up if a level was missed.

[R.D. Silverman]

Originally Posted by Brian-E

Cheesehead, I note your latest remark about LL work not currently being done by this competitor, only TF work

Request for clarification. Are they doing LL work or not??? If so, whose
CODE are they using? If they are not doing LL work at all, then their
entire effort is inconsequential.

(and Dubslow's information that they used to do LL work too). But let's assume that this new site does actually start some serious competition with GIMPS in the future if they are not already doing that now. I'd like to advocate that we welcome their initiative and let them carry on. I take this position because I don't see it as competition at all.

If they succeed in eliminating some candidates by finding small factors,
GIMPS should simply accept the information, double check that it is correct,
and say "thank you for saving us the trouble".

If a serious organisation manages to achieve some serious independent checking/verification of the results which GIMPS has already determined, that will significantly improve the confidence in those results.

Their lack of knowledge and their babbling about predicting the next
prime based on historical data makes me doubt their competence. I
do not take them seriously. Do they have a knowledgeable
mathematician who is advising them? Based on what I have seen
they would not take such advice very seriously. They'd probably
accuse him/her of being a troll.

[R.D. Silverman]

Originally Posted by bloodIce

They have two factors for small exponents on their webpage (http://mersenneathome.net/), which are not in the GIMPS database:

How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?

They are IRRELEVANT. The numbers had already been fully
tested. Knowing some new small factors does not help at all.

[davieddy]

This could be the start of a beautiful friendship

[Dubslow]

Originally Posted by R.D. Silverman

They are IRRELEVANT. The numbers had already been fully
tested. Knowing some new small factors does not help at all.

No, but PrimeNet is reporting false statements in the meantime, namely that "there are no factors below 2^62" is patently false.
http://mersenne.org/report_exponent/?exp_lo=2100451
I hope that BloodIce does create a Mersenne@Home and does report the factors. As has been noted, it seems that some of GIMPS' earlier TF could use some double checking. (No, it does not advance the search for a large Mersenne prime, but I would argue that searching for factors is no less useless than searching for primes.)

As for LL, they used to do only LL but no TF; Batalov convinced them that TF was a good idea, but now they currently do not do LL. It is their plan to resume doing LL at some point.

Why? If you look through the first page, Mr. Bobrecki believes he can use patterns in the factors to find new primes. Now, we at this forum believe this to be folly (please don't repeat this statement RDS, we are all well aware of this and more than one of us has tried to convince Mr. Bobrecki of this). However, just because we believe it to be folly does not mean that we cannot be polite to them and hopefully organize an agreement where GIMPS and Mersenne@Home do not do redundant work. Depending on how much firepower M@H collects, it would perhaps be reasonable that each exponent should have one test from each project.


@everyone, as opposed to just RDS:

One cause for concern is the speed and/or safety of their LL code. Prime95 has a lot of error catching code, as well as the infamous bit-shift.

Somewhat related to that, it would make sense to me, if this goes through (or even not), would be to add more data to each exponent that is checked. Instead of comparing the last 64 bits, we could for example compare the first 64 and the last 64 bits; or, since those data are co-located in the bit-shifted FFTs, perhaps what would make more sense is compare the last 64 bits as well as 64 bits smack in the middle of the residue. That way data from different parts of the FFT are compared.


Even if we agree to work together, somebody would need to find a way to cross-communicate between the two servers. Among other things, PrimeNet would definitely need that upgrade that's supposed to be coming soon, and even that might need to be souped up a bit. We would also need Mr. Bobrecki's agreement. Is anybody familiar with BOINC servers and/or specifically the way M@H's servers are set up? (Between frmky, chalsall and JH, if they are willing, we could probably get pretty far in getting cross server communication to work.)

[chalsall]

Originally Posted by Dubslow

We would also need Mr. Bobrecki's agreement. Is anybody familiar with BOINC servers and/or specifically the way M@H's servers are set up? (Between frmky, chalsall and JH, if they are willing, we could probably get pretty far in getting cross server communication to work.)

Trivial to set up.

But, as you say, it should only be implemented with the knowledge and agreement of Mr. Bobrecki and Mr. Woltman.

[Dubslow]

Originally Posted by chalsall

Trivial to set up.

But, as you say, it should only be implemented with the knowledge and agreement of Mr. Bobrecki and Mr. Woltman.

I was thinking more on design terms. Should one or the other be a "master" and the other grab assignments from the first? Should PrimeNet just add BOINC functionality, and have the M@H address redirect to PrimeNet? ...et cetera. That would also need to be something Messrs. Woltman, Bobrecki, and any "implementators" agree on.

[Brian-E]

Originally Posted by Dubslow

I was thinking more on design terms. Should one or the other be a "master" and the other grab assignments from the first? Should PrimeNet just add BOINC functionality, and have the M@H address redirect to PrimeNet? ...et cetera. That would also need to be something Messrs. Woltman, Bobrecki, and any "implementators" agree on.

If we go down the road of working together with M@H beyond only the most trivial level, that is beyond sharing known factors, then suddenly the entire operation becomes only as good as its weaker participant. In practical terms, that probably means a huge sacrifice of credibility by GIMPS. M@H, a new initiative with dubious ideas as indicated by Dr. Silverman, should not be allowed to contribute to the same database as the long-established GIMPS except insofar as sharing instantly-verifiable known factors.