mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > YAFU

Reply
 
Thread Tools
Old 2011-04-29, 16:39   #639
jasonp
Tribal Bullet
 
jasonp's Avatar
 
Oct 2004

3×1,181 Posts
Default

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.
jasonp is offline   Reply With Quote
Old 2011-04-30, 02:45   #640
mnh001
 
Apr 2011

26 Posts
Default

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.
mnh001 is offline   Reply With Quote
Old 2011-05-12, 08:52   #641
lorgix
 
lorgix's Avatar
 
Sep 2010
Scandinavia

3×5×41 Posts
Default

Quote:
Originally Posted by bsquared View Post
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.
It happened again;

Code:
prp39 = 105138255226693956286871224196642713681 (curve 1 stg1 B1=2000 sigma=3559889203 thread=0)
Three factors this time.

Divides (2^5807+1)/3+1.
lorgix is offline   Reply With Quote
Old 2011-05-12, 09:27   #642
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

9,497 Posts
Default

It also has these factors, obviously.
Batalov is offline   Reply With Quote
Old 2011-05-12, 09:41   #643
lorgix
 
lorgix's Avatar
 
Sep 2010
Scandinavia

10011001112 Posts
Default

Yes, and (2^5807+1)/3 has already been proven prime. Still a little curious about why the above happened.
lorgix is offline   Reply With Quote
Old 2011-05-12, 12:07   #644
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

1101110000102 Posts
Default

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
Sorry 'bout that.
bsquared is offline   Reply With Quote
Old 2011-05-17, 16:06   #645
mnh001
 
Apr 2011

26 Posts
Default

Quote:
Originally Posted by bsquared View Post
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.
Hi, how is it that you create the tune command for the ini file?
mnh001 is offline   Reply With Quote
Old 2011-05-17, 17:14   #646
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

2·3·587 Posts
Default

When you run the function tune(), a line is automatically appended to your .ini file with the tuning results.
bsquared is offline   Reply With Quote
Old 2011-05-18, 00:12   #647
mnh001
 
Apr 2011

4016 Posts
Default

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
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
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

Last fiddled with by mnh001 on 2011-05-18 at 00:15
mnh001 is offline   Reply With Quote
Old 2011-05-18, 13:08   #648
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

2·3·587 Posts
Default

Quote:
Originally Posted by mnh001 View Post
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:
Originally Posted by mnh001 View Post
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
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().
bsquared is offline   Reply With Quote
Old 2011-05-18, 14:31   #649
mnh001
 
Apr 2011

1008 Posts
Default

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
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.

Last fiddled with by mnh001 on 2011-05-18 at 14:39
mnh001 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Running YAFU via Aliqueit doesn't find yafu.ini EdH YAFU 8 2018-03-14 17:22
YAFU-1.34 bsquared YAFU 119 2015-11-05 16:24
Yafu bug. storflyt32 YAFU 2 2015-06-29 05:19
yafu-1.33 bsquared YAFU 12 2012-11-08 04:12
yafu-1.32.1 bsquared YAFU 21 2012-09-04 19:44

All times are UTC. The time now is 20:46.


Fri Aug 6 20:46:29 UTC 2021 up 14 days, 15:15, 1 user, load averages: 2.33, 2.45, 2.64

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.