[QUOTE=swellman;386115]I just got a new box and a twist on this bug has appeared.

When I run the snfs() command, yafu starts to run then gives an error of "can't open log file" and crashes.

The error is repeatable, though the place at which it crashes seems semi-random. Sometimes it crashes at the first poly, sometimes after quite a few. Changing number of threads seems to help, though I don't know why (doesn't the snfs() command only use 1 thread?). But the snfs() command never gets to the test sieving step, just crashes in the poly generation phase.

The number I am running is C158_136_134 from the xyyx project.
[code]
84311455579199090648493230576403161968451360234506586342094132063229517346160992903240099249802174895769891679510634920540783201237119607493881630083817780573
[/code]

System

AMD E2-6110 APU with AMD Radeon R2 Graphics 1.50 GHz
RAM is 4.00 Gb
Win 81. 64-bit with x64-based processor

Anyway, another data point.[/QUOTE]

Thanks for the info.

So, I re-built MPIR 2.6.0, gmp-ecm 6.4.4, and then yafu, after which everything appears to work on windows (Msys). This one runs fine (yafu ultimately picks GNFS), the [URL="http://www.mersenneforum.org/showpost.php?p=385248&postcount=300"]previous one[/URL] picked a poly and started test sieving, and [URL="http://www.mersenneforum.org/showpost.php?p=385612&postcount=15"]this bug[/URL] is also fixed.

Great news! I will rerun the bug cases on my machines, though I'm traveling this week so it may be a few days until I get to it.

Thanks for all the work.

[QUOTE=swellman;386261]Great news! I will rerun the bug cases on my machines, though I'm traveling this week so it may be a few days until I get to it.

Thanks for all the work.[/QUOTE]

Ok, but just to be clear, I haven't changed anything in either SVN or the downloadable executable... so you would have to rebuild everything yourself to see things fixed.

Ok - I (wrongly) assumed souceforge had been updated with all the executables. I can't compile on Windows. Will just have to wait for it to be compiled/tested/released formally.

But you found the underlying problem, which is very cool.

YAFU rho() performance 'bug'?
 

Hi Ben,

Pollard Rho probably isn't of much interest, but in case it is: I just spotted what appears to be a typo in rho.c around line 195:

[CODE]
for(i=0;i<=r;i++)
{
mpz_mul(t1,y,y); //y = (y*y + c) mod n
mpz_add_ui(t1, t1, c);
[B]mpz_tdiv_r(t1, t1, fobj->rho_obj.gmp_n);[/B]
}
[/CODE]
I think this line should be:
[CODE]
[B]mpz_tdiv_r([COLOR="Red"]y[/COLOR], t1, fobj->rho_obj.gmp_n);[/B]
[/CODE]

Running rho("188686371167044582826981915497892444670204038509658079137") (which is a P17.P40) the change brings the time down from 159s to 84s.

Also, I think the loop should start at i=1 rather than i=0 (or have < rather than <=), though I could be wrong...

Cheers,

Mick.

it would be great if somebody could upload a compiled Windows x64 binary with the latest corrected code, please.

Apparently Yafu is having a bug when it is factoring a number which is consisting of many small factors.

This is the main reason for why I usually do not choose to be doing just such a thing.

Factoring a number gives like a C230 from a C240 and the rest or remainder of the number is being listed without further factorization or stating whether it is composite or not.

That is when using the ecm command. Using ecm(ans,30) instead, where ans is the current number (or the number currently being factored makes it possibly to return the result to the Factor Database either using the Auto detect (slow) format or Yafu output at the bottom of the pull-down menu.

When using the ecm(ans,30) command, the remainder of the number is being listed as a P1234567891 (or P10). For the ecm(ans) command, I only get 1234567891 as the remainder of the result.

This is a silly and unncessesary bug which needs to be fixed as soon as possible!

ECM runs ECM factoring on the number, it isn't supposed to completely factorise the number.

One small thing I notice in the Yafu output is that it is a bit cramped at times.

Really I prefer to compress things myself and also when writing stuff trying to even out the sentences and not put everything in one single line or paragraph.

But just one blank line for separating the different result elements in the output gives a better look or appearance of things. There are a couple of times where I am missing this blank line.

Hopefully a small bug that could be fixed.

No idea if this is even really a yafu issue or not, but here it is [url]http://mersenneforum.org/showthread.php?p=394947#post394947[/url]

Of course it is a yafu issue! [/semi-sarcasm]
yafu should be patched to reply: x^4-1 = (x-1)(x+1)(x^2+1)
...which immediately takes care of that particular example: it gets fully factored.

More generally, yafu should not ever accept a reducible polynomial as a factorization hint.
Either bluntly dump it back to the user, or factor it algebraically internally, and only then use the part that contains the input (or as in this case: take gcd, and divide-and-conquer).