Newer milestone thread - Page 5

Primeinator · 2010-12-11, 19:21

Quote:

Originally Posted by NBtarheel_33

Only problem is that this single exponent (which is now holding up *two* milestones) is being run on a P3 by a user who updates only every 28 days, and is not due to finish the test until May of next year...

...yeah, yeah, I know, 100.00000001 is *still* faster than 100, and all that jazz.

Just think about it this way- we know that when it is updated, the apparent progress of all numbers below 'x' being tested at least once will jump by a LARGE amount.

davieddy · 2010-12-11, 20:13

Quote:

Originally Posted by davar55

That was from the MARX brothers, as i recall.

Is that some newfangled computer or summat?
How much do they know about the FA Cup?
It may well be the comfy chair for them.

Oh no!

davieddy · 2010-12-12, 03:38

Quote:

Originally Posted by davar55

That was from the MARX brothers, as i recall.

Of course.
When we know it as well as we do, it almost
invariably sounds too contrived to be funny.

But then nobody can say it like Chico!

David

Oops. That sounds like a cue for cmd:)

Uncwilly · 2010-12-12, 05:22

moderation is needed

Brian-E · 2010-12-12, 10:51

Quote:

Originally Posted by Mini-Geek

[...] While I should hope there aren't many people intentionally submitting wrong results twice (or even once!), I would be surprised if no numbers are marked as done with DC with incorrect residues due to this.[...] I'd be surprised if any primes are missed by PrimeNet, though in the future a triple check, with results only allowed through trusted sources, checking large blocks of GIMPS work would probably be worthwhile.

Mini-Geek, your suggestion that the PrimeNet database may not be completely accurate is discouraging, and I'm especially wondering if there is something new that you now know and didn't know before to explain why you have apparently changed your mind?

davieddy · 2010-12-12, 10:51

Quote:

Originally Posted by Uncwilly

moderation is needed

Another typically witty comment, obviously conducive
to veering the thread (the creation of which was totally unnecessary)
back on ANY topic.

I think there is good reason why neither you nor I (prolific
contributors as we may be) are not considered moderator material

David

davieddy · 2010-12-12, 11:13

Quote:

Originally Posted by Brian-E

Mini-Geek, your suggestion that the PrimeNet database may not be completely accurate is discouraging, and I'm especially wondering if there is something new that you now know and didn't know before to explain why you have apparently changed your mind?

I'm sure George has explained the practice before, but it could
certainly do with more publicity.

I think it goes like this:
If a second LLtest (referred to as a "Double Check" during its
execution) produces a residue different from the original, the number
is not listed as "composite" and a further test is allocated referred to
as LL rather than DC. Assuming (likely) that this residue matches one
of the previous, the number is put to bed as composite (or prime

).

Hope this post is considered on topic and constructive.
Can't think of a suitable musical accompaniment or even a jest ATM,
UncWilly will be disappointed to hear.

David

TimSorbet · 2010-12-12, 13:12

Quote:

Originally Posted by Brian-E

Mini-Geek, your suggestion that the PrimeNet database may not be completely accurate is discouraging, and I'm especially wondering if there is something new that you now know and didn't know before to explain why you have apparently changed your mind?

I wouldn't say there's new information, just a different way of looking at it. I was thinking within the normal PrimeNet framework, and mainly considering software/hardware errors instead of the effects of some kinds of cheaters/malicious people. Triple checks from regular users can't be trusted if we want 100% certainty of the GIMPS DB (after all, for completed DCs the full residue is shown; even if no credit is given anywhere for results in this triple check, you couldn't be sure they really did the work, unless they submitted results with a different shift and valid checksum; note that not all PrimeNet-allowed programs support those features!), it'd have to be a trusted third party. Within the normal PrimeNet framework, a triple check whose result doesn't match the first two would be considered wrong, but if we are doing a special check of PrimeNet/GIMPS results, we would retest it to see which is really right. Also, I think that hardware generally would produce an error every X hours of running, (instead of every X calculations) so in the future when tests can be run in a much shorter time, we'd have more reason to trust the triple check than the original tests.

Quote:

Originally Posted by Mini-Geek

I'm 99% sure that triple checks are very close to being totally useless. (unless for some other purpose...definitely not useful in the same way that double checks are useful)

I was thinking mainly of software and hardware errors here. So I still think that triple checks aren't useful (well, technically they are, but in such a ridiculously slight way it hardly matters, something like changing the chance of matching accidentally-wrong residues from 1/(2^64)^2 to 1/(2^64)^3) in the main way that double checks are, i.e. for detecting accidental errors, but they are useful in another way: detecting fraudulent results.

henryzz · 2010-12-12, 13:29

Another thing to consider is that occasional program versions have been released that aren't completely relyable(take pfgw recently for example as an extreme case). If that version does both ll and dc then we will have an error in our data.

TimSorbet · 2010-12-12, 14:54

Quote:

Originally Posted by henryzz

Another thing to consider is that occasional program versions have been released that aren't completely relyable(take pfgw recently for example as an extreme case). If that version does both ll and dc then we will have an error in our data.

Yes, but with the "different shift" requirement, I'm pretty sure the chance of a software bug like that producing identical residues is practically nil.

Brian-E · 2010-12-12, 19:24

Cheesehead also gave me a superb informative reply when I asked about this issue as a newcomer to this forum.

I suppose when you go to the lengths of verification using only a "trusted" third party (which is not, of course, a universal concept), it ceases to be a true distributed computing project.

2010-12-12, 13:29	#53
henryzz Just call me Henry "David" Sep 2007 Liverpool (GMT/BST) 37×163 Posts	Another thing to consider is that occasional program versions have been released that aren't completely relyable(take pfgw recently for example as an extreme case). If that version does both ll and dc then we will have an error in our data. Last fiddled with by henryzz on 2010-12-12 at 13:29

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Newer X64 build needed	Googulator	Msieve	75	2022-06-13 14:22
Performance of cuda-ecm on newer hardware?	fivemack	GMP-ECM	14	2015-02-12 20:10
Cause this don't belong in the milestone thread	bcp19	Data	30	2012-09-08 15:09
Newer msieves are slow on Core i7	mklasson	Msieve	9	2009-02-18 12:58
Use of large memory pages possible with newer linux kernels	Dresdenboy	Software	3	2003-12-08 14:47

2010-12-12, 05:22	#48
Uncwilly 6809 > 6502 """"""""""""""""""" Aug 2003 101×103 Posts 25213₈ Posts	moderation is needed

2010-12-12, 19:24	#55
Brian-E "Brian" Jul 2007 The Netherlands 3278₁₀ Posts	Cheesehead also gave me a superb informative reply when I asked about this issue as a newcomer to this forum. I suppose when you go to the lengths of verification using only a "trusted" third party (which is not, of course, a universal concept), it ceases to be a true distributed computing project.