mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   YAFU (https://www.mersenneforum.org/forumdisplay.php?f=96)
-   -   Yafu (https://www.mersenneforum.org/showthread.php?t=10871)

jasonp 2011-04-29 16:39

Runaways happen most often with small SNFS jobs; there is a range of dataset sizes where the linear algebra will work. Too little data and you won't get a matrix, too much data and you'll get a matrix that will not solve. With small (100-120 digit?) SNFS jobs it's quite easy to get too much data, in which case the best course is to manually do the postprocessing with *fewer* relations.

mnh001 2011-04-30 02:45

Well, I did do one restart from the filtering but it just continued with the runaway so that's when I deleted the files and started over new. Thanks.

lorgix 2011-05-12 08:52

[QUOTE=bsquared;259356]Somehow the factor must have not had a prp check... I'll have to trace through the code to see if there is a path for factors to slip past the check.

I'm guessing both factors were found simultaneously - a 32 digit factor with B1=11k would be a little improbable.[/QUOTE]

It happened again;

[CODE]prp39 = 105138255226693956286871224196642713681 (curve 1 stg1 B1=2000 sigma=3559889203 thread=0)[/CODE]Three factors this time.

[I]Divides (2^5807+1)/3+1.[/I]

Batalov 2011-05-12 09:27

It also has [URL="http://factordb.com/index.php?query=2%5E%285805%2F5%29%2B1"]these factors[/URL], obviously.

lorgix 2011-05-12 09:41

Yes, and (2^5807+1)/3 has already been proven prime. Still a little curious about why the above happened.

bsquared 2011-05-12 12:07

I found the problem - a simple typo in the record-factor-in-logfile function in my ecm function (it prints prp when it knows it is composite). The console output is correct. So it appears my isPrime function works just fine.

Here is the console output for this most recent case.
[CODE]***factors found***
P1 = 2
P1 = 2
P1 = 3
P1 = 3
P1 = 3
P2 = 11
P2 = 19
P3 = 331
P3 = 811
P4 = 1033
P4 = 1291
PRP5 = 15121
PRP5 = 87211
PRP6 = 104491
PRP7 = 9084611
PRP8 = 18837001
PRP8 = 25878691
C39 = 105138255226693956286871224196642713681[/CODE]

Sorry 'bout that.

mnh001 2011-05-17 16:06

[QUOTE=bsquared;258183]That sounds about right for 1 thread on a win64 system. And yes, you should run the tune function single threaded otherwise it won't be a fair comparison to NFS (which is always single threaded within tune()).

You might also get better QS performance if you use the 32k version of yafu on your core i3 instead of the 64k version. If not, that would be interesting to know about.[/QUOTE]
Hi, how is it that you create the tune command for the ini file?

bsquared 2011-05-17 17:14

When you run the function tune(), a line is automatically appended to your .ini file with the tuning results.

mnh001 2011-05-18 00:12

Ah, so it does. Couldn't find it in the docfile.txt. When run it created:
[code]
tune_info=Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz,WIN32,7.06528e-005,0.196179,0.419108,0.10477,95.046,2302.87
[/code]And this is the last little bit of the run:
[code]
best exponential fit is y = 0.419108 * exp(0.10477 * x)
QS/NFS crossover occurs at 95.0 digits
Adding tune_info entry for WIN32 - Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40G
Hz
invalid character in str2hexz

ans = 17301789
[/code]Except for the invalid character part, I take it the run was successful?
And the QS/NFS crossover at 95 digits, that means if a number is smaller than 95 digits it tries QS first else it runs nfs? TIA

bsquared 2011-05-18 13:08

[QUOTE=mnh001;261657]Except for the invalid character part, I take it the run was successful?

Yep. I'll put that invalid character bit on my todo list.
[/QUOTE]

[QUOTE=mnh001;261657]
And the QS/NFS crossover at 95 digits, that means if a number is smaller than 95 digits it tries QS first else it runs nfs? TIA [/QUOTE]

You got it.

The tuning info is also used to determine the "optimal" amount of ECM to run prior to either QS or NFS, if you use factor().

mnh001 2011-05-18 14:31

After sending the note I was looking at the results and realized that ans = 17301789 didn't seem proper. So I cleaned out all the created files and ran tune() again. This time it gave:
[code]
best linear fit is ln(y) = 0.105192 * x + -0.908861
R^2 = 0.968975
best exponential fit is y = 0.402983 * exp(0.105192 * x)
QS/NFS crossover occurs at 95.1 digits
found OS = WIN32 and CPU = Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz in tu
ne_info field
Replacing tune_info entry for WIN32 - Intel(R) Core(TM)2 Duo CPU T8300 @ 2.
40GHz

ans = 0
[/code]As you can see, ans=0 and there's no invalid character message. So maybe cleaning out the files from time to time is a good thing. :smile:


All times are UTC. The time now is 23:06.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.