[QUOTE=Random Poster;279963]My understanding is that if an application runs on one Mac, it will run on every Mac.[/QUOTE]Not true, AFAIK.

I've have an old iMac in my loft ...

Paul

[QUOTE=Random Poster;279963]...
How about supporting 32-bit Linux? Or at least detecting 32-bit Linux? The last time I tried to compile Yafu, gcc tried to feed 64-bit inline asm to 32-bit assembler.[/QUOTE]
Version 1.20.2-bin.zip includes 32-bit binaries and can be found [URL="http://sites.google.com/site/bbuhrow/yafu-1.20.2-bin.zip?attredirects=0"]here[/URL].

[QUOTE=Random Poster;279963] My understanding is that if an application runs on one Mac, it will run on every Mac.
[/QUOTE]

That will definately not be true of older mac's that used powerpc chips. I haven't tested the generic branch of yafu in a while, so I'm pretty sure it wouldn't build or run in that case.


[QUOTE=Random Poster;279963]
How about supporting 32-bit Linux? Or at least detecting 32-bit Linux? The last time I tried to compile Yafu, gcc tried to feed 64-bit inline asm to 32-bit assembler. [/QUOTE]

That (and the generic branch just mentioned) is on my todo list (and has been for some time unfortunately).

[QUOTE=BudgieJane;279769]
It seems strange that it appears to go into pp1 on XP but not on Win7.
[/QUOTE]

That is normal. Yafu may decide to run more "pretesting" depending on how long it has already been doing pretesing and how long it thinks it will take to finish by siqs/nfs. Since your XP system is slower than your Win7 system it isn't unexpected that it would try pp1/pm1/ecm before starting siqs.

[QUOTE=BudgieJane;279769]
What, if anything, am I doing wrong? [/QUOTE]

Nothing, as far as I can see. It could be because one or more of the gmp-ecm/gmp/msieve libraries as I compiled them are incompatible with the P4 hardware (I recall that I may have compiled with -march=core2, so possibly the compiler inserted instructions illegal on the P4).

In hindsight it's perhaps a bad decision, but I've always provided optimized binaries (generally for the latest intel hardware) rather than generic ones.

What's with this error and how can I get rid of it? Mention that the program runs normal, sieving, finding the right factors (except their size, which is still not corrected, some factors are indicated as being one digit higher, but this I don't mind), but the error regularly appears every 8-10 lines in poly selection phase. Sometime rubbish characters appear too, but this is only cosmetic (threads fight each other to print on screen, and messages are sometime mixed from different threads).

"Error generating or reading NFS polynomials" just means that Msieve did not find an NFS polynomial in the factor-base file. If you're only searching a small range and have a big input, then this can easily happen.

[QUOTE] If you're only searching a small range ... [/QUOTE]

Yep, and this is just what yafu does in order to facilitate threading.

@LaurV:
FWIW, you can set the batch size handed out to each thread with the option -pbatch <num>. Increasing from the default of 250 may help, if the error messages sufficiently offend you :) They are harmless, in the grand scheme of things, and have been there all along (just unnoticable in the midst of all the screen spam). Note that doing so may also make the search time deadline harder to meet, since the ranges must finish before timing measurements are taken.

[QUOTE=bsquared;280231] They are harmless..[/QUOTE]
Well, what I have learned from my grandpa: if it works, don't fix it! I will not touch it! And I will not change the batch size. Happy with its current speed.
Thanks both of you!

yafu 1.29 throwing exceptions in rho/pm1/pp1 for couples of small numbers
 

@bsquared:

I am trying to go through the aliquots starting with 6^7 and 6^9. Yafu 1.29 is killing me this time, both 32 and 64 bit versions. Took them apart to avoid any interference with aliqueit program. For the most of the small numbers I tried, newest yafu pops different exceptions, including "division by zero" once (!?), and for few of them is effectively LOCKED without saying nothing.

Try for example:
yafu factor(44088137814965903154255010553749)
(I have a whole list of 100 numbers, if you get no issue for this one)
You can try a couple of "factor(rsa(x)" with x in 107-113 range, or around, and you will SURELY find one. Bigger or smaller values for rsa will not complain, and work generally well finding the right factors. Tried rsa(110) 20 times, all except 3 complained about reading wrong memory area or dividing by zero in rho or pp/pm.

The yafu_32_win32 will just die (locked) without any exception. The other flavours will raise the debugger.

The former 1.28.5 goes through all of them small numbers without any difficulty, if the 32_win32 version is used. The other versions still pop the exception or lock.

For v1.29.1: In one case the exception says "Access violation reading location 0x0064d000." and it is thrown always in the same place of the code, on the other case the exception says "Integer division by zero" and it is thrown always in the same place of the code too (but different place from the first case).

If you need, I can provide photo snaps from VS2005 Just-In-Time debugger.

now another one:

try this:

yafu factor(460707809)

then check the log file.

No factors.
No wonder aliqueit says "no factors found on factor.log file", and then loops forever trying to increase the ecm bounds until some allocation error could occur... then exits cussing me...

edit: the number resulted from aliquot 10077696 (which is 6^9) at the term T2836 and it is the product of that two small, almost equal, P5's (21269*21661) I factored it by hand :D then I realized the screen output is right of yafu, it shows the factors (bat was disappearing too fast, I had to launch it in a separate cmd prompt), but only the output to factor.log is wrong. Affected: all versions and flavors of yafu (the older versions too).

[QUOTE=LaurV;280626] Try for example:
yafu factor(44088137814965903154255010553749)
[/QUOTE]

Thanks for the test case - problem found and fixed (also thanks to Brian Gladman for jumpstarting the bugfix).

I'll update the download here in a bit.