![]() |
[QUOTE=Batalov;292204]M( 5xxxxxxx )C, 0xdb8f585db0b58a3e, n = 3145728, CUDALucas v1.64
It was a match. Good news for CUDALucas v1.64 and the card.[/QUOTE] It also proves that the newest version of Prime95 is working correctly - at least for the most part. :-) |
[QUOTE=Batalov;292221]But was I talking about other Mersennes? For them, penultimate iteration value [tex]\neq \pm \sqrt 2[/tex].[/QUOTE]
And how do ye know? Ye don't. Take any exponent, all of them have sqrt(2), which is 2^((p+1)/2) or its negative. For example, 2^((5+1)/2)=2^3=8 is the square root of 2 mod M5, because 8^2=64=2 mod 31, and so is its negative, -8=23 mod 31. Then, of course, you [B]can[/B] reach 8 in LL sequence from only 2 values, [B]because[/B] M5=31 is prime. That means either 8+2 or 23+2 is a quadratic residue (inclusive or). Because 31 is [B]3 mod 4[/B], that is why they both are QR. And indeed, you [B]can[/B] get 10 by squaring 14 or by squaring -14=17, and you can get 25 by squaring 5 or by squaring -5=26 mod 31. And so, you [B]can[/B] store your 4 values in a list (5, 14, 17, 26), and [B]in case you get a zero during LL test[/B], you [B]can [/B]check if the previous residue is in the list, and if not, some calculation errors occurred. Wasn't that the idea? Well, if so, it was bad. Because you can do this process only when Mp is prime. And this, you DON'T KNOW. If you knew, then no testing would be need. You know only that you got a zero in some LL iteration, and you want to check if it was not an error, by looking to the former residue, which must be a trivial square root of two. Here you stop. You can't continue with the list of 4 values, for a non-prime mersenne, that list does not exist. [B]That was my point.[/B] You [B]can't[/B] do it when Mp is not prime, because sqrt(sqrt(2)+2) in that case is QNR, and its negative the same, and even if you try to extract the square root, that process would be equivalent with a LL test. Take p=11 for example, you have the two sqrt(2) being 64 and 1983, but none of 66 or 1985 are QR. Even if you try to extract the square root of them, you have to raise 66 (for example) at the power of Mp/4, which is equivalent with a LL test (same number of operations). So, when Mp is not prime, you CAN NOT create your list. If you find a very fast method to extract the square root from 2^((p+1)/2)+2 mod Mp, much faster then doing a LL test, then you have a way to "filter" the exponents [B]faster then LL testing them[/B]. In fact, you do not have to compute it effectively, it would suffice to decide if it is QR or QNR. And you can simplify it further by taking out a 2, which is always QR. For example M11=2047, we have that 2 is always QR, so sqrt(66)=sqrt(2*33)=sqrt(2)*sqrt(33). If you can decide "superfast" if 33 is QNR, then M11 is composite. And so for any exponent p, if you can decide very fast if 2^((p-1)/2)+1 is QNR, then Mp is composite (because it would be no way to reach 0 in [B]ANY[/B] number of iterations in LL test). But for that, you have to extract the root effectively, by raising 33^M11/4 (you will always get a result) and then square the result to see if you get 33. This is same number of operations as a LL test. |
You are familiar with the fact that the L-L test is both necessary and sufficient for Mp to be prime? So, if the final residue is 0, then Mp is prime and that is the only context where we are interested in the sign of the [URL="http://www.mersenneforum.org/showthread.php?t=5862"]penultimate iteration[/URL].
|
Man, I have nothing to argue against your penultimate iteration. That is sqrt(2) and always exists, and is trivial to compute. If you get a 0 in some LL iteration, you can always check if the previous iteration is sqrt(2) or its negative. If it is not, then there was an error.
My whole argument is and was only against the list with 4 (FOUR) numbers which come before the penultimate iteration, and started as a joke (trying to slap you on that phrase, see the end of your post #109). If you get a zero, to be able to check against the "4 values" list, you have to build it before. And that does not exists, for a not-prime mersenne. And for a prime to build it, it would be equivalent with a (new) LL test by itself. [edit: you forgot where all this discussion started: someone get a 0 on "some" LL iteration, being that the last one or not, is not important. Then the one, he wants to check if the zero is "legitimate" or it was an error in the last computed iteration. He can check if the one-before-last is sqrt(2) (or its negative), which is trivial to compute. That is [B]all he can do[/B]. He can't go further, to check the "list of 4" (as you said in post #109), the "list of 8" or whatever. Those lists do not exist for a non-prime, and you DON'T KNOW if your mersenne is prime. You got a zero, so what? That could mean you have a calculus error or a "cosmic ray" wondering inside of your processor :D, or whatever... The primality come only AFTER you are sure that yout LL test is right, and this is exactly what you want to find out.] |
You got it all wrong. This is only to extend [URL]http://oeis.org/A123271[/URL] without re-running the whole Lucas sequence. And not to fight technical issues (false positives) which are mundane.
[QUOTE=LaurV;292291]...[edit: you forgot where all this discussion started: someone get a 0 on "some" LL iteration, being that the last one or not, is not important. [/QUOTE] and don't put words in my mouth. My remark started with George's willingness to put some more code in the "maybe-we-have-good-news state" of the program which has nothing to do with zero happening in "some" iteration. It has already been discussed that if "zero happened not in the last iteration", the last iteration will not be zero and there will be no false positive reported. There's plenty of 000000000000002 residues - search the database - and they don't cause a "Another success"/"Holy Batman" thread. P.S. See [URL="http://www.mail-archive.com/mersenne@base.com/msg08205.html"]here[/URL] - "After M29 was discovered, that was the very first question Dick Lehmer asked. I think it interested him more than the value of p!! --Luke Welsh" Who are we to argue with D.L.?! |
This all discussion is EXACTLY about fighting technical issues. It was started with George's question at the end of post #67 on page 3:
[QUOTE]The open question is what is causing these? Prime95 detects any zeroing of an intermediate iteration. It also detects any illegal floating point numbers (NaNs). I can't think of any other sanity checks to add.[/QUOTE]and "extending whatever oeis sequence" was not mentioned till a minute ago, by yourself. We talked about everything, naked women, blogs, bla bla bla, but NEVER about extending nothing. Coming back to the point: I am doing a LL test and got a ZERO residue in the LAST (if you want) iteration. What should I do to avoid reporting a false positive?? You replied in post #109 that checking if the former iteration is plus or minus square root of two. I agree. Then you said: "the second next to last would be one of the 4 values"... Slap! Slap! That is all... If I got you wrong, I am taking back mi slaps: !palS !palS... :razz: |
[QUOTE=LaurV;292309]We talked about everything, naked women, blogs, bla bla bla, but NEVER about extending nothing.[/QUOTE]
That's what you guys talked about. By all means, continue. You were arguing with post #109. Reread it. This question is 20+ years old, so don't tell me that I made it up in #126 -- it is stated in #109. And lastly, yes, there are bleeding 4 possible values for the next-to-penultimate iteration for a Mp, p>3. Calculate (+- 2[SUP](p+1)/2[/SUP]+2 | 2[SUP]p[/SUP]-1). Both are 1. Except of course for p<=3, but those LL sequences don't [I]have[/I] a next-to-penultimate iteration, just {0} and {4,0}. |
[QUOTE=Batalov;292311]That's what you guys talked about. By all means, continue.
You were arguing with post #109. Reread it. This question is 20+ years old, so don't tell me that I made it up in #126 -- it is stated in #109. And lastly, yes, there are bleeding 4 possible values for the next-to-penultimate iteration for a Mp, p>3. Calculate (+- 2[SUP](p+1)/2[/SUP]+2 | 2[SUP]p[/SUP]-1). Both are 1. Except of course for p<=3, but those LL sequences don't [I]have[/I] a next-to-penultimate iteration, just {0} and {4,0}.[/QUOTE] Ok, I can't argue with you after you changed the avatar to that nice picture :P Your "reference" to "extending whatever list" in post 109 was not so clear, as the "extension" process itself was not mentioned by anyone that time, but now after this all discussion I can see that your post #109 could be interpreted like that. I am sorry that I was mis-interpreting it. Mea culpa. Sorry that I am such a bitch :D... Now to tie all lost ends: 1. "There's plenty of 000000000000002 residues - search the database" could you point me to some of them, below 30M, except 10230383 which is clear a coarse error? 2. "there are bleeding 4 possible values for the next-to-penultimate iteration for a Mp, p>3", again, assuming that iteration gave you a zero residue, this could be true only if Mp is a prime. Which, in our context, you don't know. Your zero-result could be a computing error. |
[QUOTE=LaurV;292312]
1. "There's plenty of 000000000000002 residues - search the database" could you point me to some of them, below 30M, except 10230383 which is clear a coarse error? [/QUOTE] At my last download on December 24, 2011 (well, the small exponents--where everything was double-checked--were downloaded before that date): 431441, 3729053, 5025467, 5986987, 6409307, 10230383, 26556359, 27000139. There is also a 0000000000000004 at 4098607. |
[QUOTE=patrik;292325]At my last download on December 24, 2011 (well, the small exponents--where everything was double-checked--were downloaded before that date):
431441, 3729053, 5025467, 5986987, 6409307, 10230383, 26556359, 27000139. There is also a 0000000000000004 at 4098607.[/QUOTE] I would doubt the [5,5,5,1,5,5,5,1] mod 6 repeats. |
[QUOTE=patrik;292325]At my last download on December 24, 2011 (well, the small exponents--where everything was double-checked--were downloaded before that date):
431441, 3729053, 5025467, 5986987, 6409307, 10230383, 26556359, 27000139. There is also a 0000000000000004 at 4098607.[/QUOTE] 27000139 was mine: It was a bad build of CUDALucas. |
| All times are UTC. The time now is 06:50. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.