Factoring projects algorithms - What is Aliqueit ?

[bsquared]

Originally Posted by bsquared

Regarding SVN, I'm just trying to say to use the latest version of the YAFU code, which I have kept up-to-date in the repository but not on the main page, whose code dates back over a year now (version 1.34.5). (From the main page, click on the 'code' tab, then perform an SVN checkout from your linux environment using either the command line or your favorite SVN client (I use tortoise).)

I just realized that all of the newest code is not in /trunk. I've been putting everything in /branches/wip.

Try checking out that code and rebuilding. Sorry about that...

[Romuald]

Anyway, I don't think it would bring about major change, does it?

[Romuald]

matthias@matthias-Aspire-V3-771G:~/Téléchargements/programs/yafu-code$ ./yafu -v 

08/19/16 14:34:49 v1.34.5 @ matthias-Aspire-V3-771G, System/Build Info: 
Using GMP-ECM 7.0.3, Powered by GMP 6.1.1
detected        Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
detected L1 = 32768 bytes, L2 = 3145728 bytes, CL = 64 bytes
measured cpu frequency ~= 2594.042160
using 1 random witnesses for Rabin-Miller PRP checks

We can obviously see it uses GMP and GMP-ECM properly.
I don't see any other crucial informations to put in the yafu.ini, however I'm not an expert.
Currently I have 4 lines of tune_info:

tune_info=Intel(R) Xeon(R) CPU           X5460  @ 3.16GHz,LINUX64,2.18911e-05,0.202416,0.389149,0.100747,96.2505,3158.64 
tune_info=Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz,LINUX64,3.49486e-05,0.196117,0.457315,0.0986543,97.2601,2926.14 
tune_info=Intel(R) Xeon(R) CPU           X5687  @ 3.60GHz,WIN64,2.17215e-005,0.198989,0.289067,0.104803,100.823,3559.71 
tune_info=Intel(R) Xeon(R) CPU           X5680  @ 3.33GHz,LINUX64,2.20817e-05,0.199481,0.407936,0.0991673,97.9339,3325.09

that have been set during the install I guess. I didn't touch it though it's quite evidently not correct.

NB: This is still the install from svn checkout svn://svn.code.sf.net/p/yafu/code/trunk yafu-code, I didn't get the newest from your rectification B² yet.

[LaurV]

Originally Posted by Romuald

Currently I have 4 lines of tune_info:

Delete them, or put them in the comment to keep them for posterity and/or for historical purposes, or whatever (I am always a packrat!) and run the tune command again.
edit: for experts/experienced users, you have to type ./yafu -tune

[Romuald]

Originally Posted by LaurV

Delete them, or put them in the comment to keep them for posterity and/or for historical purposes, or whatever (I am always a packrat!) and run the tune command again.
edit: for experts/experienced users, you have to type ./yafu -tune

Why again ?

I never did it before. Anyway, I always have this damned seg fault.

It starts to be annoying to me and I think that henceforth I'm going to run YAFU as a single program, 'cause I find this assembly with GGNFS and GMP/GMP-ECM is definitively shaky/dicey (well, that's my opinion).

[Romuald]

I think my computer is playing tricks to me. I just tried again today unziping all my files of source codes and binaries, and guess what, when I called yafu to factor a very large number (I tried successively with numbers more and more big until a 604-bits one to be sure) and I didn't get this damned segmentation fault, the ECM data comes in uninterrupted streams on the terminal tab.

And for the first numbers, around 100 digits and more, I was first surprised to dee that YAFU was factoring them rather quickly compared to usual single-handed YAFU factorization. I deduced it was the speed improvements due to the other programs alongside.

For instance, I factorized this 455-bits number in 0.3238 secs which is, from what i can remember, quite fast on my own computer.
63740574903749027942156975423697452139327549709654710975420967235906729124603749521079432541684616065415056410654168416510651684611065163

Thank you all of you for working this out.

[EdH]

Sorry I haven't been around lately to answer questions about my page. But, glad to see you are making headway with your system.

A few answers, that are probably of no real value now:

I have recently updated my page for 64-bit installations.

The formerly working GitHub version of ggnfs has apparently been modified to fail now.

I no longer reference or use antiX. antiX is a linux distribution based on Debian and can be researched on the web. Although it ran fine for me, there were embedded propaganda files in the distribution. I elected to strip my page down to Ubuntu, which supports all my needs so far in math computing.

[Romuald]

Yes, Ubuntu is also a great tool in math for me as a student. I discovered sagemath about 1 ½ year ago, that's a tool I often use, with python (and other libraries), and now factoring tools, although I can't really understand them in the deep mathematical background. I suppose I'll have to wait a little bit more before studying that.

Concerning this number above, I finally have to put it into perspective, it was not an RSA number. I mean, it was totally random and its factors are not 2 great prime numbers.

I have currently a 512-bits RSA number in the process of factorization, after solving the path problem. It's long.

Is there any existing plot of the time of factorization through YAFU vs the bits number of an integer?

[Dubslow]

It's roughly subexponential. Here's a plot of NFS and QS timings (assuming ECM doesn't find small factors of course): http://www.mersenneforum.org/showthr...225#post423225

[Romuald]

Ok, thanks, it might help me estimating the necessary time, the only linear factor being the power of calculus of the computer.