yafu bugs

[swellman]

Originally Posted by bsquared

I was having the same problem over here. Not sure what's causing it, but it doesn't seem to be related to yafu. The linux version (with the x86_64 assembler improvements) doesn't have the problem.

OK, thanks for the response. I'll try this composite again on different machines once I return home (currently traveling).

I have been considering installing Ubuntu (dual boot) on one of my Windows boxes. Never played with Linux, but it sounds like it's a lot more non-CS user friendly than it was 10 years ago when I last considered making the plunge.

Is the performance increase in factoring under Linux substantial enough to justify the pain of the learning curve? Just curious.

[Dubslow]

Originally Posted by swellman

OK, thanks for the response. I'll try this composite again on different machines once I return home (currently traveling).

I have been considering installing Ubuntu (dual boot) on one of my Windows boxes. Never played with Linux, but it sounds like it's a lot more non-CS user friendly than it was 10 years ago when I last considered making the plunge.

Is the performance increase in factoring under Linux substantial enough to justify the pain of the learning curve? Just curious.

You might consider a virtual box with Linux inside Windows. The gain from 64bit/assembly routines is significant enough that even inside a virtual box, it's still quite a bit faster.

[Kosmaj]

Seconding the following idea. It's exactly what I wanted to suggest.

Originally Posted by bsquared

No problem.

It would be easy to do. Options are fun!

Originally Posted by jcrombie

re: making the crossover point an option, that might not be a bad idea. I suspect that even with 300 digit numbers, there could be a speed improvement. And making this an option would somewhat "document" what is going on.

[swellman]

Dubslow

Maybe I'll try the virtual box thing too (on a machine separate from the Ubuntu dual boot). Thanks for the suggestion.

bsquared
Would I be out of line starting (or requesting) a "YAFU on Linux" thread? While there are a good number of posts discussing Linux on MF (including the Linux subforum), they are often about very specific or scattered subjects and often years out of date. If nothing else, it might help Linux newbs like myself get started using YAFU on Linux even if it is just links to relevant posts around the forum.

[Dubslow]

Originally Posted by swellman

bsquared
Would I be out of line starting (or requesting) a "YAFU on Linux" thread? While there are a good number of posts discussing Linux on MF (including the Linux subforum), they are often about very specific or scattered subjects and often years out of date. If nothing else, it might help Linux newbs like myself get started using YAFU on Linux even if it is just links to relevant posts around the forum.

It's not really different from Windows AFAIK. You open a terminal, change to the YAFU dir, "./yafu" and off you go. But feel free to start a thread.

[bsquared]

Originally Posted by jcrombie

It was just a misunderstanding then. I had "-pretest 20" which implied B1=11e3 and would of been below that limit.

re: making the crossover point an option, that might not be a bad idea. I suspect that even with 300 digit numbers, there could be a speed improvement. And making this an option would somewhat "document" what is going on.

SVN 240

[jcrombie]

Originally Posted by bsquared

SVN 240

Seems to be working just fine! Thanks again!

btw, the option, which is not documented, is "-ext_ecm N" where N is the crossover point.

eg. "-ext_ecm 10000" to start multi-threaded ecm'ing at B1=11000.

[bsquared]

You got it, sorry about that. I'll update the documentation before releasing the next version.

[swellman]

I think I've found the source of my earlier problems combining nfs.dat files between win32 snd win64 boxes - the nfs.dat files from the win32 machines are compressed. Once I extracted the win32 .dat files, there were fully compatible with my win64 boxes.

Can the ZLIB=1 feature (or whatever is causing this) be turned off when compiling the win32 YAFU binaries in the next release? I know it was an issue during a past release, looks like win32 slipped by somehow. No biggie if it can't be removed - now that I know it's there, I can just extract the data file when moving it from a win32 to a win64 box.

[VolMike]

I have a problem with -op in yafu 1.32.1 win32.
F.e. when written in windows batch file
%yafu_path% "factor(12234765987623896452346987687998273465234523452345234523452345798768769876842376985762345)" -op primes.txt -threads 4 -plan normal -p -ecm_path %ecm_path%

yafu completes factorization but doesn't create primes.txt. All other parameters are used in factorization process (4 threads, gmp_ecm in ecm stage, etc). What's wrong with -op. Is that well known bug, or am I doing something wrong?

[WraithX]

Originally Posted by VolMike

I have a problem with -op in yafu 1.32.1 win32.

yafu completes factorization but doesn't create primes.txt. All other parameters are used in factorization process (4 threads, gmp_ecm in ecm stage, etc). What's wrong with -op. Is that well known bug, or am I doing something wrong?

The purpose of -op is to check if an input number is prime or prp and then "O"utput that "P"rime number to a file.

If you'd like to save all the factors of an input number out to a file you can use the -of option, which will "O"utput "F"actors to a file.

There is also a -ou option which will "O"utput an "U"nfactored number to a specified file if yafu knows that the input number is composite, but was unable to find any factors before stopping.