No retest is needed.  The numbers were found quickly due to not having to
"backtrack".

The code computes 2^(2^1832495), 3^(2^1832496), 5^n 7^n, 11^n.

It then tries to find factors.  NOTE it may have to backtrack.  It did in all
xGF cases, until it got to the xGF(11,???).  All of them were to the 1832495
value, thus a simple GFN addition was all that was needed to determine the exact
factor.  That is quick.  All exponentations were done prior, and were used.

Note, that GF-3 and GF-11 imply xGF(11,3).   Look at the factors found.  I think
all of the xGF were trivial.   Even the xGF(9,5)  is trivial due to factors GF-3
and GF-5

Jim.

---- j_m_berg <j_m_berg@...> wrote:
> I ran into something that seems rather odd and most likely erroneous.
> As you can see from the command line, I was testing for GF and xGF
> cases on a rather large Proth prime. It appeared to work properly
> until near the end. Then it finished in a matter of a second or two.
>
>
> Factor of GF(1832495,11)!!!! (1232842.226000 seconds)
> This line was generated in less than one second of wall clock time.
>
>
> The five following lines were reported as taking 0.016 - 0.0 seconds.
>
>
> Any ideas on what happened?
>
>
> My guess is that these GF/xGF tests need to be retested. But it
> brings to question as to whether any of the earlier tests are
> accurate.
>
>
>
>
>
>
> C:\Numbers\Proth>start /b /wait /low pfgw -gxo -a2 "-q3*2^1832496+1"
> PFGW Version 1.2.0 for Windows [FFT v23.8]
>
> 3*2^1832496+1 is a Factor of GF(1832490,3)!!!! (45688.339000 seconds)
> 3*2^1832496+1 is a Factor of GF(1832494,5)!!!! (45562.769000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,5,3)!!!! (91282.260000
> seconds)
> 3*2^1832496+1 is a Factor of GF(1832494,7)!!!! (45663.183000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,7,3)!!!! (91174.010000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832490,7,5)!!!! (91302.650000
> seconds)
> 3*2^1832496+1 is a Factor of GF(1832494,8)!!!! (45617.694000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,8,3)!!!! (91370.248000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832493,8,5)!!!! (91574.809000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832493,8,7)!!!! (91508.339000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,9,5)!!!! (91444.837000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,9,7)!!!! (91333.664000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832494,9,8)!!!! (91353.475000
> seconds)
> 3*2^1832496+1 is a Factor of GF(1832495,11)!!!! (1232842.226000
> seconds)
> 3*2^1832496+1 is a Factor of xGF(1832495,11,3)!!!! (0.016000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832495,11,5)!!!! (0.000000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832495,11,7)!!!! (0.015000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832495,11,8)!!!! (0.000000 seconds)
> 3*2^1832496+1 is a Factor of xGF(1832495,11,9)!!!! (0.000000 seconds)
>
> C:\Numbers\Proth>
>
>
>
> The OpenPFGW project: http://www.primeform.net/openpfgw
> Yahoo! Groups Links
>
>
>

What caused me the most concern was the 1232842.226000 time shown. Note
that the wall clock time for the GF(11) case was on the order of 1-2
seconds, yet it gave a time of 1232842.226000 seconds for this step.

The 1232842.226000 seconds was the actual entire CPU time per Task
Manager and not the actual time required for this single step.




--- In openpfgw@yahoogroups.com, <jfoug@...> wrote:
>
> No retest is needed.  The numbers were found quickly due to not
having to "backtrack".

At 11:32 PM 10/8/2007, you wrote:
>1) Is the 24.9 FFT version working properly on numbers of the form
>k*2^n+/-c where c is greater than 1?

The gwnum library is indeed too aggressive in choosing FFT sizes.  I'm
working on isolating the problem.  Unfortunately, any fix will appear
in the 25.6 library.  Worse yet, the interface to the gwnum library
has changed in order to support multithreading.

If we're lucky, the fix will be a simple C code fix such that the 24.9 library
can be patched.

At 09:58 PM 10/16/2007, you wrote:
>At 11:32 PM 10/8/2007, you wrote:
> >1) Is the 24.9 FFT version working properly on numbers of the form
> >k*2^n+/-c where c is greater than 1?

Background:   FFT sizes have been set by trial and error using lots of
Mersenne-only data over many years.  When upgrading the FFTs to
handle a wider variety of numbers, k*2^n+c, I needed to understand
how k and c affect how many data bits can be stuffed in an FFT input word.

Theoretically, a k value > 1 adds log2(k) bits to every FFT word.  Actual
data over the last few years has shown this theory matches quite well with
reality.

The trouble occurs with abs(c) > 1.  In this case the DWT weights vary
from 1 to c.  Whereas in the Mersenne case and the abs(c) == 1 case
every FFT word had the same number of bits, in this case the smallest
FFT data words will have log2(abs(c)) bits less than the largest FFT words.

I ran some tests, and doubling the c value made the maximum roundoff error
triple (roughly).   Thus, in 24.9 I reserved room for 1.5 *
log2(abs(c)) bits in
the FFT input words.

Phil has found some cases where this fails.  Perhaps, he has found some
cases where the DWT weights are not randomly distributed.  I've changed the
code to reserve 1.8 * log2(abs(c)) bits for each input word.   This
is pessimistic for
almost all large c values - but better safe than sorry.  I'm running
24 hours of random
k,n,c tuples that are near the limits of an FFT length to see if I
need to be even
more strict.  This change is pretty easy to make in 24.9, email me and I
can send instructions.

Is it possible to build and run pfgw on SunOS 5.10 ?
I tried to build it on

SunOS 5.10 Generic_118844-26 i86pc i386 i86pc

but I got the following error:

make[3]: Entering directory `/tmp/openpfgw_v12/packages/gmp/doc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/tmp/openpfgw_v12/packages/gmp/doc'
make[3]: Entering directory `/tmp/openpfgw_v12/packages/gmp'
make[3]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
make[2]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
make[1]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
/tmp/openpfgw_v12/../make-3.81/make -C pform/pflib
make[1]: Entering directory `/tmp/openpfgw_v12/pform/pflib'
g++ -s -O2 -ffloat-store -funroll-loops -fomit-frame-pointer -I. -
I../.. -c -o ipfsymbol.o ipfsymbol.cpp
In file included from pfstring.h:11,
from ipfsymbol.h:5,
from ipfsymbol.cpp:3:
pffastbuffer.h: In copy constructor `PFFastBuffer<T>::PFFastBuffer
(const PFFastBuffer<T>&)':
pffastbuffer.h:40: error: `m_pBuffer' undeclared (first use this
function)
pffastbuffer.h:40: error: (Each undeclared identifier is reported
only once for each function it appears in.)
pffastbuffer.h:40: error: `m_dwAllocated' undeclared (first use this
function)
pffastbuffer.h: In member function `PFFastBuffer<T>&
PFFastBuffer<T>::operator=(const PFFastBuffer<T>&)':
pffastbuffer.h:49: error: `m_dwAllocated' undeclared (first use this
function)
pffastbuffer.h:51: error: `m_pBuffer' undeclared (first use this
function)
pffastbuffer.h:57: error: `m_dwGrow' undeclared (first use this
function)
pffastbuffer.h: In member function `virtual void
PFFastBuffer<T>::Resize(DWORD)':
pffastbuffer.h:65: error: `m_dwAllocated' undeclared (first use this
function)
pffastbuffer.h:68: error: `m_pBuffer' undeclared (first use this
function)
pffastbuffer.h:70: error: there are no arguments to `Allocate' that
depend on a template parameter, so a declaration of `Allocate' must
be available
pffastbuffer.h:70: error: (if you use `-fpermissive', G++ will accept
your code, but allowing the use of an undeclared name is deprecated)
pffastbuffer.h: In member function `virtual void
PFFastBuffer<T>::RemoveCell(DWORD, DWORD)':
pffastbuffer.h:82: error: `m_dwAllocated' undeclared (first use this
function)
pffastbuffer.h:86: error: `m_pBuffer' undeclared (first use this
function)
pffastbuffer.h: In member function `virtual void
PFFastBuffer<T>::InsertCell(DWORD, DWORD)':
pffastbuffer.h:95: error: `m_dwAllocated' undeclared (first use this
function)
pffastbuffer.h:99: error: `m_pBuffer' undeclared (first use this
function)
pffastbuffer.h: In member function `virtual DWORD
PFFastBuffer<T>::Find(const T*, DWORD, DWORD) const':
pffastbuffer.h:110: error: `m_pBuffer' undeclared (first use this
function)

The strange behaviour is that on a Linux machine the build works fine
but , on the SAME SOURCE CODE LINES OF THE SUN OS ERROR, gives the
following warnings:

../../pform/pflib/pfstring.h: In instantiation of
`PFGenericString<char>':
../../pform/pflib/ipfsymbol.h:9:   instantiated from here
../../pform/pflib/pffastbuffer.h:105: warning: `DWORD
    PFFastBuffer<T>::Find(const T*, long unsigned int, long unsigned
int) const
    [with T = char]' was hidden
../../pform/pflib/pfstring.h:358: warning:   by `DWORD
    PFGenericString<T>::Find(const PFGenericString<T>&) const [with T
= char]'

Any hints ?



--- In openpfgw@yahoogroups.com, "m34890721" <m34890721@...> wrote:
>
> Is it possible to build and run pfgw on SunOS 5.10 ?
> I tried to build it on
>
> SunOS 5.10 Generic_118844-26 i86pc i386 i86pc
>
> but I got the following error:
>
> make[3]: Entering directory `/tmp/openpfgw_v12/packages/gmp/doc'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/tmp/openpfgw_v12/packages/gmp/doc'
> make[3]: Entering directory `/tmp/openpfgw_v12/packages/gmp'
> make[3]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
> make[2]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
> make[1]: Leaving directory `/tmp/openpfgw_v12/packages/gmp'
> /tmp/openpfgw_v12/../make-3.81/make -C pform/pflib
> make[1]: Entering directory `/tmp/openpfgw_v12/pform/pflib'
> g++ -s -O2 -ffloat-store -funroll-loops -fomit-frame-pointer -I. -
> I../.. -c -o ipfsymbol.o ipfsymbol.cpp
> In file included from pfstring.h:11,
> from ipfsymbol.h:5,
> from ipfsymbol.cpp:3:
> pffastbuffer.h: In copy constructor `PFFastBuffer<T>::PFFastBuffer
> (const PFFastBuffer<T>&)':
> pffastbuffer.h:40: error: `m_pBuffer' undeclared (first use this
> function)
> pffastbuffer.h:40: error: (Each undeclared identifier is reported
> only once for each function it appears in.)
> pffastbuffer.h:40: error: `m_dwAllocated' undeclared (first use this
> function)
> pffastbuffer.h: In member function `PFFastBuffer<T>&
> PFFastBuffer<T>::operator=(const PFFastBuffer<T>&)':
> pffastbuffer.h:49: error: `m_dwAllocated' undeclared (first use this
> function)
> pffastbuffer.h:51: error: `m_pBuffer' undeclared (first use this
> function)
> pffastbuffer.h:57: error: `m_dwGrow' undeclared (first use this
> function)
> pffastbuffer.h: In member function `virtual void
> PFFastBuffer<T>::Resize(DWORD)':
> pffastbuffer.h:65: error: `m_dwAllocated' undeclared (first use this
> function)
> pffastbuffer.h:68: error: `m_pBuffer' undeclared (first use this
> function)
> pffastbuffer.h:70: error: there are no arguments to `Allocate' that
> depend on a template parameter, so a declaration of `Allocate' must
> be available
> pffastbuffer.h:70: error: (if you use `-fpermissive', G++ will
accept
> your code, but allowing the use of an undeclared name is deprecated)
> pffastbuffer.h: In member function `virtual void
> PFFastBuffer<T>::RemoveCell(DWORD, DWORD)':
> pffastbuffer.h:82: error: `m_dwAllocated' undeclared (first use this
> function)
> pffastbuffer.h:86: error: `m_pBuffer' undeclared (first use this
> function)
> pffastbuffer.h: In member function `virtual void
> PFFastBuffer<T>::InsertCell(DWORD, DWORD)':
> pffastbuffer.h:95: error: `m_dwAllocated' undeclared (first use this
> function)
> pffastbuffer.h:99: error: `m_pBuffer' undeclared (first use this
> function)
> pffastbuffer.h: In member function `virtual DWORD
> PFFastBuffer<T>::Find(const T*, DWORD, DWORD) const':
> pffastbuffer.h:110: error: `m_pBuffer' undeclared (first use this
> function)
>

Hello group,

Do you have any idea why openpfgw systematically crashes on systems
with xeon processors ?

I have 2 servers, one linux box and one windows box with xeon
processors and openpfgw crashes on both systems. Even pfgw -i fails
(with SIGSEGV on Linux).
I edited pfgw.ini file and deactivated all CPUSupportXYZ options but
with no benefit.

My version of pfgw is "PFGW Version 1.2.0 for Pentium and compatibles
[FFT v23.8]"

Is there a specific version of openpfgw for xeon platforms ?

Thank you

Best reagrds,

j_chrtn

Not sure on Windows, but on Linux, it's failing because NX (no
execute) or XD (execute disable) is set in your BIOS.  This is
designed to prevent some trojans since data regions can't be executed.
  This, however, does also catch some legitimate programs such as the
portion of the pfgw linux binary that checks which processor you are
using.  If you disable NX or XD in your BIOS, the pfgw linux client
should work.

A new binary hasn't been produced since the source needs work to be
able to even compile it with GCC 3 or 4.  Always a project for another
day...

Greg

--- In openpfgw@yahoogroups.com, "j_chrtn" <j_chrtn@...> wrote:
>
>
> Hello group,
>
> Do you have any idea why openpfgw systematically crashes on systems
> with xeon processors ?
>
> I have 2 servers, one linux box and one windows box with xeon
> processors and openpfgw crashes on both systems. Even pfgw -i fails
> (with SIGSEGV on Linux).
> I edited pfgw.ini file and deactivated all CPUSupportXYZ options but
> with no benefit.
>
> My version of pfgw is "PFGW Version 1.2.0 for Pentium and compatibles
> [FFT v23.8]"
>
> Is there a specific version of openpfgw for xeon platforms ?
>
> Thank you
>
> Best reagrds,
>
> j_chrtn
>

Hi Greg,

--- In openpfgw@yahoogroups.com, "gchil0" <jgchilders@...> wrote:
>
> Not sure on Windows, but on Linux, it's failing because NX (no
> execute) or XD (execute disable) is set in your BIOS.  This is
> designed to prevent some trojans since data regions can't be
executed.
>  This, however, does also catch some legitimate programs such as the
> portion of the pfgw linux binary that checks which processor you are
> using.  If you disable NX or XD in your BIOS, the pfgw linux client
> should work.
>
> A new binary hasn't been produced since the source needs work to be
> able to even compile it with GCC 3 or 4.  Always a project for
another
> day...
>
> Greg


You're perfectly right! I've check my W2003SP2 server and my Linux
server and both have NX activated.
Thanks a lot for your answer.

On my 2003 server, I added an exception for pfgw (advanced tab in "My
computer" control panel) and now pfgw works fine.

For the Linux server, however, I have a problem : a cat /proc/cpuinfo
shows (report for CPUs 1 to 3 ommitted) :

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Xeon(TM) CPU 3.40GHz
stepping        : 3
cpu MHz         : 3392.318
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
pbe nx lm pni monitor ds_cpl est cid xtpr
bogomips        : 6787.33

As you can see, NX is set in the CPU flags. My problem is that I
found no option in the server's BIOS to disable the NX feature.

So, do you know whether there's an option in the Linux kernel to
disable it, at least at boot time, or maybe dynamically at runtime
just like it's possible with Windows 2003 ? (I'm thinking of
something like a cat "0" > /proc/some-path/nx-stuff)

Best Regards,

j_chrtn

> As you can see, NX is set in the CPU flags. My problem is that I
> found no option in the server's BIOS to disable the NX feature.
>
> So, do you know whether there's an option in the Linux kernel to
> disable it, at least at boot time, or maybe dynamically at runtime
> just like it's possible with Windows 2003 ? (I'm thinking of
> something like a cat "0" > /proc/some-path/nx-stuff)
>

I don't know of any way to do it at runtime.  I think you can disable
NX at boot by passing the option noexec=off to the kernel.  If you use
grub, you can just add it to /boot/grub/menu.lst so that it happens
every time.

Greg

Can someone help me at all please (I've looked in the 'files' section, and also
can't see an
obvious FAQ, but...)
I want to verify primality of a few PRPs (as above). I only have linux/Mac
platforms available. I
have been using Francois Morain's ECPP, but that is taking a while...
Somebody (Rick Shepherd) suggested openpfgw (at least I think that's the exact
version he
meant), but I don't know much about it.
I'd appreciate help in answer to the following three questions:
a) Is it likely this is what he meant?
b) Is this (ie openpfgw) a good idea (for this task)?
c) If so, instructions, please?!!
thanks,
James (Wanless)

Only if you know 33% of the factors of N-1 or N+1.  You can use KP if
you know 30% of the factors, and CHG if you know >25% (or perhaps 26%
in practice).  Otherwise, you are only left with ECPP.  Primo is the
only publicly released ECPP implementation as far as I am aware.  It's
only distributed as a Windows binary, but it works fine in Wine.  Has
fastECPP been released?  I would make good use of it...  :-)

Greg

--- In openpfgw@yahoogroups.com, "James Wanless" <james@...> wrote:
>
> Can someone help me at all please (I've looked in the 'files'
section, and also can't see an
> obvious FAQ, but...)
> I want to verify primality of a few PRPs (as above). I only have
linux/Mac platforms available. I
> have been using Francois Morain's ECPP, but that is taking a while...
> Somebody (Rick Shepherd) suggested openpfgw (at least I think that's
the exact version he
> meant), but I don't know much about it.
> I'd appreciate help in answer to the following three questions:
> a) Is it likely this is what he meant?
> b) Is this (ie openpfgw) a good idea (for this task)?
> c) If so, instructions, please?!!
> thanks,
> James (Wanless)
>

--- In openpfgw@yahoogroups.com, "gchil0" <jgchilders@...> wrote:
>
> Only if you know 33% of the factors of N-1 or N+1.  You can use KP if
> you know 30% of the factors, and CHG if you know >25% (or perhaps 26%
> in practice).  Otherwise, you are only left with ECPP.  Primo is the
> only publicly released ECPP implementation as far as I am aware.  It's
> only distributed as a Windows binary, but it works fine in Wine.  Has
> fastECPP been released?  I would make good use of it...  :-)
>
> Greg
>
> --- In openpfgw@yahoogroups.com, "James Wanless" <james@> wrote:
> >
> > Can someone help me at all please (I've looked in the 'files'
> section, and also can't see an
> > obvious FAQ, but...)
> > I want to verify primality of a few PRPs (as above). I only have
> linux/Mac platforms available. I
> > have been using Francois Morain's ECPP, but that is taking a while...
> > Somebody (Rick Shepherd) suggested openpfgw (at least I think that's
> the exact version he
> > meant), but I don't know much about it.
> > I'd appreciate help in answer to the following three questions:
> > a) Is it likely this is what he meant?
> > b) Is this (ie openpfgw) a good idea (for this task)?
> > c) If so, instructions, please?!!
> > thanks,
> > James (Wanless)
> >
>

Hi (once again) Greg,
and thanks for your help.
I successfully d/led pfgw_ver_12_linux (from the other/user group) and also got
it running
in an old(er) Linux (FC1).
From this I was able to have a play with the -t and -h options, and so I think I
understand
your comments/suggestions - for which thank you very much...!
Since my numbers have no really special helpful form ie I don't know N-1, N or
N+1
factorizations easily - I will probably have to stick to ECPP (I'm using V6.4.5a
atm - I don't
_think_ that that _is_ "FastECPP"), but I'm pleased I managed to understand this
alternative
option, and grateful for your response.
I'll keep the tip about Primo under Wine in reserve, too...
regards,
James

> I'll keep the tip about Primo under Wine in reserve, too...
> regards,
> James

Primo 3.0.6 is artificially capped at 3000 decimal digits. You will
have to look for the 2.3.3 somewhere on the web. /wink-wink/ ... try
the Files section in the xyyxf yahoo group.

I've been curious myself, and ran three of the near-repunit numbers,
and I am still running a couple of XYYX prps. One of the is Greg's if I
am not mistaken, btw. (Ah yes, it is. 2240^87+87^2240, prp4345. Runs
for a week already. Cracked away only 1/12th of the bits.)

Serge

Where is the current source for PFGW?  The only source in the group is for the
version using
the v23 Woltman libraries.  The newer executable (the one supporting IBDWT and
v24
Woltman libraries) does not seem to have any source for it.

It would be nice to get it so that I can build it on MacIntel and update to the
v25 libraries.  Is
there a project in SourceForge?  If not, there should be one.

Mark & all,
   I have ample free time (been sick, but getting better now) and am
willing to help / work to put together the appropriate Linux versions.
(32 bit dynamic & static, AND (if possible) 64 bit gmp libs & topside
with the updated 32 bit libraries.

Please let me know if I can be of assistance.

Chuck



--- In openpfgw@yahoogroups.com, "Mark Rodenkirch" <mgrogue@...> wrote:
>
> Where is the current source for PFGW?  The only source in the group
is for the version using
> the v23 Woltman libraries.  The newer executable (the one supporting
IBDWT and v24
> Woltman libraries) does not seem to have any source for it.
>
> It would be nice to get it so that I can build it on MacIntel and
update to the v25 libraries.  Is
> there a project in SourceForge?  If not, there should be one.
>

Hello fellow group members,

After a long time I rear my head by posting a proof for a Wagstaff
number primality test.

This test is similar to the well known Lucas Lehmer test and aslo
uses the iteration s -> S^2-2.  Let p>3 and prime, W_p=(1/3)(2^p+1)
then primality is given if and only if S_p = S_2 for S_0 = 6.

The complete proof in a pdf file is in the file section of this forum
(last entry in the list) or you could pick it up on below URL.
http://www.mersenneforum.org/showpost.php?p=144516&postcount=1

I would appreciate feedback especially from David as I really dipped
deep into theory.

I really hope we can move some entries from Henri Lifchitz's list.

best regards
Anton

--- On Sun, 10/5/08, Anton Vrba <antonvrba@...> wrote:
> Hello fellow group members,
>
> After a long time I rear my head by posting a proof for a
> Wagstaff
> number primality test.

This would be better on the primenumbers list.

> http://www.mersenneforum.org/showpost.php?p=144516&postcount=1

"Consider an element w ... that has no solution w^k == 1"

is meaningless.

Skipping everything before it, (19) seems to be obviously false, as the order
you've specified does not divide the order of the group.

Phil

--- In openpfgw@yahoogroups.com, Phil Carmody <thefatphil@...> wrote:

> > http://www.mersenneforum.org/showpost.php?p=144516&postcount=1
> > "Consider an element w ... that has no solution w^k == 1"
> is meaningless.

1) As Phil noted, there is horrific garbling of
the meaning of "order".

2) The use of "i" for sqrt(-1) is meaningless,
since W_p = 3 mod 4.

3) Anton has not yet proven that he did not divide by 0,
when "using (12a) and (12b) to cancel the delta".

4) His group of "all the numbers (a+b*sqrt(2)) + (a-b*sqrt(2))
modulo q which are invertible" is not Z_q[sqrt(2)]*.

5) The fundamental unit is u=1+sqrt(2), with norm -1.
So by working only with u^2, with norm +1, Anton
misses out on some of the content of the theorems
in Section 4.2 of Crandall and Pomerance.

6) We are left with nothing beyond CP Theorem 4.2.8, which
requires us to factorize at least 1/3 of the digits of W_p+1,
as in PFGW.

David

--- In openpfgw@yahoogroups.com, "David Broadhurst" <d.broadhurst@...>
wrote:

> 2) The use of "i" for sqrt(-1) is meaningless,
> since W_p = 3 mod 4.

I meant that there is no such "i" in Z_{W_p}.
In Z_{W_p}[sqrt(2)], we make take
i = 2^((p-1)/2)*sqrt(2),
so that i^2+1 = 3*W_p = 0 mod W_p.

David

I have had no contact from anyone with access to the source built on
the v24 gwnum library.  Jim Fougeron has not answered any e-mails so I
don't know if he is a member of this list anymore.  If anyone on this
list maintains regular contact with him, could you please let him know
that I am looking for the source code?

Thanks,
      Mark

Thank you Phil and thank you David for pointing out my mistakes

I cannot transfer to the other forum as my privallages are not enough
to upload files.

Instead of trying to fix the divide by 0 (which it is not but I
cannot prove) and find another wriggle (I learned my lesson) every
thing landed in the bin.

But, I am a quick learner, and I knew I was on the right track but
did not see the obvious solution.

The clue is in the paper of Shallit&Vasiga Theorem 12 showing the
elegant way to express S_2 = S_p in terms of alpha which then is
factorised to give alpha^m=1. This alone does not define the order of
\alpha but after doing the same on S_1 = -S_{p-1} the second equality
was derived for \alpha^n=-1.

This result was then plugged into the method of Bruce to complete the
proof. There is no real innovative thinking other than knowing that a
second identity had to be found - the result was always there but
nobody picked up the penny. My only claim to fame is S_1 = -S_p-1 and
to use it to find the elusive proof - the mathematical brains are by
others.

The proof is now oh so simple, but it gave me a big headache for a
number of days till the obvious was found.

The new version can be found in the file menu.

best regards
Anton

the correct file version is 2.0

--- In openpfgw@yahoogroups.com, "Anton Vrba" <antonvrba@...> wrote:
>
> Thank you Phil and thank you David for pointing out my mistakes
>
> I cannot transfer to the other forum as my privallages are not
enough
> to upload files.
>
> Instead of trying to fix the divide by 0 (which it is not but I
> cannot prove) and find another wriggle (I learned my lesson) every
> thing landed in the bin.
>
> But, I am a quick learner, and I knew I was on the right track but
> did not see the obvious solution.
>
> The clue is in the paper of Shallit&Vasiga Theorem 12 showing the
> elegant way to express S_2 = S_p in terms of alpha which then is
> factorised to give alpha^m=1. This alone does not define the order
of
> \alpha but after doing the same on S_1 = -S_{p-1} the second
equality
> was derived for \alpha^n=-1.
>
> This result was then plugged into the method of Bruce to complete
the
> proof. There is no real innovative thinking other than knowing that
a
> second identity had to be found - the result was always there but
> nobody picked up the penny. My only claim to fame is S_1 = -S_p-1
and
> to use it to find the elusive proof - the mathematical brains are
by
> others.
>
> The proof is now oh so simple, but it gave me a big headache for a
> number of days till the obvious was found.
>
> The new version can be found in the file menu.
>
> best regards
> Anton
>

--- In openpfgw@yahoogroups.com, "Anton Vrba" <antonvrba@...> wrote:

> This result was then plugged into the method of Bruce to
> complete the proof.

I append the message that I sent to Anton, showing why Bruce's
argument works for Mersenne primes, but not for Wagstaff primes.

It seems from
http://www.mersenneforum.org/showpost.php?p=144953&postcount=54
that Anton has now withdrawn his claim.

> From: "David Broadhurst" <D.Broadhurst@...>
> To: <antonvrba@...>
> Cc: <d.broadhurst@...>
> Subject: Re: Primality Proof for Wagstaff numbers (1/3)(2^p+1)
> Date: 08 October 2008 21:05

Dear Anton

> why you are still unconvinced

When N=(2^p+1)/3 is prime, it is proven that

(1+x)^(N+1) = -1 mod(x^2-2,N) ... (1)

Suppose that (1) holds and that N is composite
with a prime divisor q < sqrt(N).

Then we know that the order of 1+sqrt(2) in Z_q[sqrt(2)]*
is a divisor of 2*(N+1) and is less than N-1.
You have NO argument that there is no such divisor.
***************************************************

Contrast this with the situation for the
Lucas-Lehmer test with a Mersenne prime.

When M=2^p-1 is prime, it is proven that

(2+y)^((M+1)/2) = -1 mod(y^2-3,M) ... (2)

As shown by Bruce, this test also proves that M is prime.
Bruce's argument is very simple. Suppose that q is
a prime dividing M. Then the order of 2+sqrt(3) in Z_q[sqrt(3)]*
is precisely equal to M+1 = 2^p, since (2) shows that it
cannot be any proper divisor of 2^p.
But the order cannot exceed q^2-1.
Hence q = M and M is prime.
***************************

Now observe the huge difference between the Wagstaff and Mersenne
cases. In the latter, the order cannot be a proper divisor of M+1.
In the former, it /can/ be a proper divisor of 2*(N+1), which
may have many odd prime factors. All we can conclude from
the minus in (1) is that the order is 8*d where d is a divisor of
(N+1)/4 = (2^(p-2)+1)/3 and hence d is odd.
If we can factorize 33.33% of the digits of N+1,
we may be able prove the primality of N.
But you /never/ considered the odd divisors of N+1.

Thus you were doomed to fail.
*****************************

David

--- In openpfgw@yahoogroups.com, "David Broadhurst" <d.broadhurst@...>
wrote:
>
>
> It seems from
> http://www.mersenneforum.org/showpost.php?p=144953&postcount=54
> that Anton has now withdrawn his claim.
>
>

Seems is the incorrect word - Has withdrawn is correct

I did type an apology to be posted on this forum - It seems I did not
hit the send button!

best regards
Anton

My oversight, is that my claim to the order of $\alpha$ is wrong. The
proof of Bruce works because when he states $\omega^{2^p}=1$ and
$\omega^{2^{p-1}}=-1$ then the order of $\omega$ is $2^p$ because $2^
{p-1}$ has no odd factors and not because it is half of $2^p$ which
was my big oversight.


--- In openpfgw@yahoogroups.com, "Anton Vrba" <antonvrba@...> wrote:
>
> the correct file version is 2.0
>
> --- In openpfgw@yahoogroups.com, "Anton Vrba" <antonvrba@> wrote:
> >
> > Thank you Phil and thank you David for pointing out my mistakes
> >
> > I cannot transfer to the other forum as my privallages are not
> enough
> > to upload files.
> >
> > Instead of trying to fix the divide by 0 (which it is not but I
> > cannot prove) and find another wriggle (I learned my lesson)
every
> > thing landed in the bin.
> >
> > But, I am a quick learner, and I knew I was on the right track
but
> > did not see the obvious solution.
> >
> > The clue is in the paper of Shallit&Vasiga Theorem 12 showing the
> > elegant way to express S_2 = S_p in terms of alpha which then is
> > factorised to give alpha^m=1. This alone does not define the
order
> of
> > \alpha but after doing the same on S_1 = -S_{p-1} the second
> equality
> > was derived for \alpha^n=-1.
> >
> > This result was then plugged into the method of Bruce to complete
> the
> > proof. There is no real innovative thinking other than knowing
that
> a
> > second identity had to be found - the result was always there but
> > nobody picked up the penny. My only claim to fame is S_1 = -S_p-1
> and
> > to use it to find the elusive proof - the mathematical brains are
> by
> > others.
> >
> > The proof is now oh so simple, but it gave me a big headache for
a
> > number of days till the obvious was found.
> >
> > The new version can be found in the file menu.
> >
> > best regards
> > Anton
> >
>

Maybe just a side remark: Please check the sources, if you happen to
get the newest ones. I have been checking the prime 847*2^519964 + 1,
which I found by using llr. WinPFGW (the newest alpha version however
reported it to be composite, while the older WinPFGW (Version 1.30)
and proth.exe agree that it is prime:

PFGW Version 20050213.Win_Dev (Alpha/IBDWT 'caveat utilitor')

***WARNING! file input.txt may have already been fully processed.

847*2^519964+1 is composite: RES64: 491C123CE9BDDEFA
(604.6203s+0.0010s)
Done.
Using v24fft.DLL, version FFTVer=24.9, DllVer=1.1.5

Rüdiger

Hi Rüdiger,

Your statement that
> PFGW Version 20050213.Win_Dev (Alpha/IBDWT 'caveat utilitor')
shows
> 847*2^519964+1 is composite:
is disturbing.

However as can be seen below it is fine on my machine
( are you overclocking?)

C:\primestuff\pfgw>pfgw -f0 -n -q(847*2^^519964+1)
PFGW Version 20050213.Win_Dev (Alpha/IBDWT 'caveat utilitor')
Using v24fft.DLL, version FFTVer=24.9, DllVer=1.1.5

No factoring at all, not even trivial division
(847*2^519964+1) is 3-PRP! (1789.3845s+0.0031s)

cheers
Ken

<< endl;--- In openpfgw@yahoogroups.com, "ruediger_eckhard"
<Ruediger_Eckhard@...> wrote:
>
> Maybe just a side remark: Please check the sources, if you happen
to
> get the newest ones. I have been checking the prime 847*2^519964 +
1,
> which I found by using llr. WinPFGW (the newest alpha version
however
> reported it to be composite, while the older WinPFGW (Version 1.30)
> and proth.exe agree that it is prime:
>
> PFGW Version 20050213.Win_Dev (Alpha/IBDWT 'caveat utilitor')
>
> ***WARNING! file input.txt may have already been fully processed.
>
> 847*2^519964+1 is composite: RES64: 491C123CE9BDDEFA
> (604.6203s+0.0010s)
> Done.
> Using v24fft.DLL, version FFTVer=24.9, DllVer=1.1.5
>
> Rüdiger
>

Hi group,

Can anyone tell me (or even better send me) where I can find the latest
(statically compiled if possible) version of openpfgw for Linux or at
least where I can get the latest source code.

The 20041023_Linux_Dev_Beta_pfgw.gz version from the "Files" repository
doesn't work on Linux systems that have the NX CPU flag enabled and I
can't find more recent versions for Linux (either the sources or
compiled).

Thanks,

j_chrtn