Re: Generalized fermats
- --- In primenumbers@y..., "Yves Gallot" <galloty@w...> wrote:
>> When i look at the largest primes of this form i see a lot of lines likeI have a newer version of GFNSieve which instead of telling you that the
>> 3078 4448982^4096+1 27232 g144 2001 Generalized Fermat
>> But proth.exe doesn't allow me to check numbers higher then 3298768.
>> Doesn't a gxxx code mean the number is tested with proth.exe?
>They were: you can check numbers higher then 3298768 for N=4096 with
>Proth.exe. The bound is just for "standard" mode. The program doesn't check
>it with "File" mode. It is not a bug, it was done to allow "advanced" users
>to extend the search.
>A tricky usage of GFNSieve, by making a file with the numbers to be sieved
>and setting the program to continue, generates the input file.
numbers are too large and failing to allow you to continue, it warns you that
the numbers are too large, but does allow you to continue if you click "Yes"
telling the program that you know you are getting out of the "standard" limits
of Proth.exe. I will try to get this version built, regression tested, and
posted to the primenumbers file section soon.
> I fixed the bounds bMax such that the FFT error is about 0.1. I tested the
> range 3300000-3600000 for N=4096 and found about the expected number of
> primes. Then if we continue the search for b > bMax, we can hope to find
> about all primes until ... an unknown limit today. David Underbakke started
> to explore this unknown area until the test will fail: that is really an
> experimental search. The higher you go above the standard Proth ranges, the
> greater the risk that you will miss primes, and be wasting your computer
> A new feature of Proth 6.7 should be used for this search. If you check the
> "balanced 16-bit representation" in the preferences, the proof of the
> GF prime is done with a simple base 2^16 algorithm based on the reciprocal
> of the number. This is to guarantee the numbers you find are really prime.
> This mode is also the default mode for the "verifier" mode. Then now, you
> can verify that 73612720^4096+1 is prime.
> About all the ranges for N=4096 and b > 3298768 are being tested today. I
> started a search for N=8192 and David Underbakke some for N=16384. If you
> want to search in these risky ranges, send a mail to me to reserve some.
Yves Gallot wrote:
> I fixed the bounds bMax such that the FFT error is about 0.1.Does this mean that about 10% of primes near the upper bound Proth reports
the absolute value of n! less any prime larger than n
is either 1 or prime or divisible only by primes
larger than n.
For example 9! = 362880 less 11, 13, 17, 19, etc
produces 362869 (divisible by 13 and 103 and 271),
362867 (prime), 362863 (prime), 362861 (divisible by
109 and 3329) etc.
16 Nassau Street
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
- At 12:06 AM 8/11/01 +0400, Andrey Kulsha wrote:
>Hello!The 0.1 is an error, and does not correlate to percentage of the primes
>Yves Gallot wrote:
>> I fixed the bounds bMax such that the FFT error is about 0.1.
>Does this mean that about 10% of primes near the upper bound Proth reports
missing near the upper bound. The error must be less than 0.5 to get a
correct answer. If the error is less than 0.5, that alone does not
guarantee a correct answer. Where between 0.1 and 0.5 do primes start to be
improperly reported as composite? At this time no one knows. Some of my
tests indicate that there are failures significantly below 0.5. Will the
failure be gradual or sudden? Again no one knows at this time.
In my opinion, the current bMax value is fairly conservative to make sure
users find all the primes in ranges they are searching. Above the current
bMax values, there is increasing risk that primes will be reported as
composite. The degree of risk has not been quantified at this time.