![]() |
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.
|
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.
|
[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] |
It also has [URL="http://factordb.com/index.php?query=2%5E%285805%2F5%29%2B1"]these factors[/URL], obviously.
|
Yes, and (2^5807+1)/3 has already been proven prime. Still a little curious about why the above happened.
|
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. |
[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? |
When you run the function tune(), a line is automatically appended to your .ini file with the tuning results.
|
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 |
[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(). |
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.