Request from Phil

[axn]

Originally Posted by fatphil

So, those who are familiar with the concept of how I code - stuff's _always_ work in progress (ask Mark - he's had 5 code drops in as many days!) - are invited to volunteer to help me test this on real-world candidates. Please state chip type and OS, so we can work out the best way to get an executable to you (I build or you build).

Are the residues compatible with PRP/LLR Res64? If not, we may have a problem for double checking? [It is ok for testing phase, but for ongoing use by the project, it could be a problem]

[rogue]

Originally Posted by axn1

Are the residues compatible with PRP/LLR Res64? If not, we may have a problem for double checking? [It is ok for testing phase, but for ongoing use by the project, it could be a problem]

Unfortunately no.

One thing Phil forgot to mention was a bug fix in the yeafft source. I don't know if it affects these tests. I also don't recall exactly what the fix was (the code isn't in front of me). Either Phil or I can relay that information later in this thread.

Also, Phil and I (more Phil than I) are trying to address an overflow bug on non-x86 compatible CPUs.

[axn]

Originally Posted by fatphil

So, those who are familiar with the concept of how I code - stuff's _always_ work in progress (ask Mark - he's had 5 code drops in as many days!) - are invited to volunteer to help me test this on real-world candidates. Please state chip type and OS, so we can work out the best way to get an executable to you (I build or you build).

So how do I volunteer for this? I have a Pentium M running Win XP Pro.

[rogue]

Originally Posted by rogue

One thing Phil forgot to mention was a bug fix in the yeafft source. I don't know if it affects these tests. I also don't recall exactly what the fix was (the code isn't in front of me). Either Phil or I can relay that information later in this thread.

In yeainit.c, add the middle line to y_init()as follows:

y_size_t y_init(y_size_t n)
{
n+=(n&1); /* round up to even, as we must be even sized */

y_size_t i = (1L << (sizeof(y_size_t) * 8 - 2)), j,
k = sizeof(y_size_t) * 8 - 1, old = Y_LENGTH;

[fatphil]

Originally Posted by axn1

So how do I volunteer for this? I have a Pentium M running Win XP Pro.

Yeugh.

I have a cygwin/p3 build that works, but my cygwin/p4 binary doesn't.
I will try to build a P4 FFT with a P3 modular maths wrapper tomorrow, and ship you the fastest thing that has no known failure cases. It might be the old cygwin/p3 binary though, if I have no luck.

I'm on-site with a client nearly up in lapland currently, so am very busy and don't have particularly regular internet access, but I'll do my best.

Phil

[axn]

Originally Posted by fatphil

Yeugh.

Hey, cut it out!

Originally Posted by fatphil

I have a cygwin/p3 build that works, but my cygwin/p4 binary doesn't.
I will try to build a P4 FFT with a P3 modular maths wrapper tomorrow, and ship you the fastest thing that has no known failure cases. It might be the old cygwin/p3 binary though, if I have no luck.

In my experience, P3 builds are better for P-M's than P4 builds, and plain x86 FPU is better than SSE2.

[fatphil]

Originally Posted by axn1

Hey, cut it out!

In my experience, P3 builds are better for P-M's than P4 builds, and plain x86 FPU is better than SSE2.

I've found some real bugs with YEAFFT when compiled for P4 with SSE2, so am not prepared to release code based on that library. So the P3 library it is.

Alas I don't have the right machine with me, and I can't build an executable until monday. But I'll upload a tarball of binary and source then.

Phil

[rogue]

Originally Posted by fatphil

I've found some real bugs with YEAFFT when compiled for P4 with SSE2, so am not prepared to release code based on that library. So the P3 library it is.

Alas I don't have the right machine with me, and I can't build an executable until monday. But I'll upload a tarball of binary and source then.

Phil

Phil, I have a P3, so unless there is anything special you need me to do, I can build an executable on it.

[fatphil]

Originally Posted by fatphil

Alas I don't have the right machine with me, and I can't build an executable until monday. But I'll upload a tarball of binary and source then.

Phil

And now is then.

Anand - this (binary) is intended only for your use, but others are permitted to be curious of course. It's been built for a plain old P3.

Mark - the source is the latest latest - the "1st line" bug is fixed.

Note - _ONLY_ Riesel (k*b^n-1) forms are supported presently. If Proth forms are required, they are simple to add, but I would rather optimise/debug one form first, and then just flip signs as the very last step.

If you can tell me unambiguously what a LLR residue represents, then I will look into trying to mimic it.

Phil

[fatphil]

Methods of running Phrot:

0) Test an 'ABC' file
1) Test a single number
2) Test a bunch of expressions
3) Advanced stuff


0) Test an ABC file.
phrot.cygp3 {filename}
Where {filename} is the name of the ABC file.
The ABC file must have a header of the form
ABC {k}*{b}^{n}-1
where {k}, {b}, and {n} are either ABC variables ($a, $b, $c, any order) or are small constants. {k} is the only one that may be more than a million.
The rest of the file must be parameter values to replace $a, $b, $c in the expression, just like any ABC files always have been.

1) Test a single number
phrot.cygp3 -q {expression}
Where {expression} is an expression of the form {k}*{b}^{n}-1 where {k}, {b}, {n} are small constants as above.

2) Test a bunch of expressions (such as a pfgw.log file)
phrot.cygp3 {filename}
Where {filename} is the name of the file containing the expressions. Phrot will detect that it's not an ABC file, and then parse each line exactly as in (1) above.

3) Advanced stuff
a) If you give it '--' as the filename, then it will read expressions/values from standard input. e.g.
grep '-1$' pfgw.log | phrot.cygp3 --
b) If you use the -q switch with an expression with ABC variables in it, then it will proceed as if that expression was the header for an ABC file as in (0) above.
grep -v ':' sieveoutput.npg | phrot.cygp3 -q '$a*5^$b-1'


Note - there is no resume feature yet. Edit your ABC files to remove tested candidates before restarting.

[tnerual]

i tried it just to see the speed difference.

i got some problem.
first: i had to rename it as a .exe file (in my case phrot.exe) to get it running. (easy to solve)
second: i had to download the cygwin1.dll (easy to solve)

third: when trying to run it i got this output:

phrot -q 285728*5^411274-1
Error: base out of range
285728*5^411274-1
^ near here

i'm using a centrino 1.4 with win xp supposed to be the same architecture as a p3.
caan someone help me ?