mersenneforum.org > YAFU Using -work but with a fraction of the size
 Register FAQ Search Today's Posts Mark Forums Read

 2018-09-25, 11:27 #1 ricky   May 2018 43 Posts Using -work but with a fraction of the size Hi all, I have a question about yafu. Is it possible to use the -work option to say yafu that I have already done a certain t-level, but using a fraction of the size of the number? Something like -work_fraction 0.1 will mean, on a C130, -work 13. The reason to wanting this is that I want to test several numbers, that are in a file, with first of all -plan light, and then something longer on the remaining numbers, but I do not want to redo the work I've already done. Thank you !
2018-09-27, 14:26   #2
bsquared

"Ben"
Feb 2007

70418 Posts

Quote:
 Originally Posted by ricky Hi all, I have a question about yafu. Is it possible to use the -work option to say yafu that I have already done a certain t-level, but using a fraction of the size of the number? Something like -work_fraction 0.1 will mean, on a C130, -work 13. The reason to wanting this is that I want to test several numbers, that are in a file, with first of all -plan light, and then something longer on the remaining numbers, but I do not want to redo the work I've already done. Thank you !
If I understand you correctly, you want to use -pretest together with -work.

 This could over-test some numbers, depending on the range of sizes in your file, but it is the cleanest way available to not redo work over a range of inputs. You could remove the smallest numbers from the file as -work increases.

-pretest <num> will test the numbers up to t<num>, regardless of their size
Next just use
-work <prevnum> -pretest <newnum>

Example:
Code:
./yafu "factor(rsa(300))" -pretest 20 -v -threads 8

<snip>

>> fac: factoring 1570043679675205080620130669902055405981262411879929087672357832941249962339901412722872057
fac: using pretesting plan: normal
fac: custom pretesting limit is: 20
fac: no tune info: using qs/gnfs crossover of 95 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 200 iterations on C91
rho: x^2 + 2, starting 200 iterations on C91
rho: x^2 + 1, starting 200 iterations on C91
pm1: starting B1 = 150K, B2 = gmp-ecm default on C91
fac: setting target pretesting digits to 20.00
fac: estimated sum of completed work is t0.00
fac: work done at B1=2000: 0 curves, max work = 30 curves
fac: 30 more curves at B1=2000 needed to get to t20.00
ecm: 30/30 curves on C91, B1=2K, B2=gmp-ecm default
fac: setting target pretesting digits to 20.00
t15: 1.00
t20: 0.04
fac: estimated sum of completed work is t15.18
fac: work done at B1=11000: 0 curves, max work = 74 curves
fac: 72 more curves at B1=11000 needed to get to t20.00
ecm: 72/72 curves on C91, B1=11K, B2=gmp-ecm default
fac: setting target pretesting digits to 20.00
t15: 7.00
t20: 1.01
t25: 0.05
fac: estimated sum of completed work is t20.24
Total factoring time = 2.0374 seconds
followed by:
Code:
./yafu "factor(input)" -work 20 -pretest 25 -v -threads 8
<snip>

>> fac: factoring 1570043679675205080620130669902055405981262411879929087672357832941249962339901412722872057
fac: using pretesting plan: normal
fac: custom pretesting limit is: 25
fac: no tune info: using qs/gnfs crossover of 95 digits
fac: input indicated to have been pretested to t20.00
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 200 iterations on C91
rho: x^2 + 2, starting 200 iterations on C91
rho: x^2 + 1, starting 200 iterations on C91
fac: setting target pretesting digits to 25.00
t15: 6.31
t20: 1.05
t25: 0.05
fac: estimated sum of completed work is t20.26
fac: work done at B1=50000: 1 curves, max work = 214 curves
fac: 204 more curves at B1=50000 needed to get to t25.00
ecm: 204/204 curves on C91, B1=50K, B2=gmp-ecm default, ETA: 0 sec
fac: setting target pretesting digits to 25.00
t15: 35.45
t20: 10.76
t25: 1.01
t30: 0.06
fac: estimated sum of completed work is t25.32
Total factoring time = 4.4135 seconds

Last fiddled with by bsquared on 2018-09-27 at 14:38

 2018-09-27, 16:39 #3 ricky   May 2018 43 Posts Thank you, this is probably the most reasonable thing to do. What I wanted was something like doing -plan light once for all numbers in a batch file, and then switching to plan normal for the remaining numbers, but of course without redoing what I've already done. In any case using -work I can more or less obtain the same result.
2018-09-27, 17:40   #4
bsquared

"Ben"
Feb 2007

3,617 Posts

Quote:
 Originally Posted by ricky Thank you, this is probably the most reasonable thing to do. What I wanted was something like doing -plan light once for all numbers in a batch file, and then switching to plan normal for the remaining numbers, but of course without redoing what I've already done. In any case using -work I can more or less obtain the same result.
I believe I see a fairly easy way to implement what you want but I don't have time right now to do it. Here is a sketch (for you, if you have the interest and some C coding skills and can compile yafu, or for me, for future reference).

In driver.c, in the applyOpt function, case 58 (near line 2315), allow for a user to input the string "light", "normal", or "deep" (the plan options), in addition to the usual numeric input. "custom" could probably also be accommodated by allowing the input of a number less than 1.

In factor_common.c, function init_factor_work, just before the if/else branching near line 2030, check to see if initial_work is equal to whatever special values were selected for that purpose in applyOpt, if the plan strings were input. init_factor_work knows the size of the current input, so initial_work could be changed at that point to the value that would have been the final result of the indicated plan.

Example:
"-work light" would put the value -1 (or whatever) into autofact_obj.initial_work.
init_factor_work would then see that initial_work == -1, and change it to be
autofact_obj.initial_work = 2/9 * size(input)
The rest of the code proceeds as normal.
if initial work is a number between 0 and 1, use that as an indication of a custom plan. Work levels between 0 or 1 would not otherwise ever occur, so that should be ok.

2018-09-27, 17:58   #5
bsquared

"Ben"
Feb 2007

3,617 Posts

Quote:
 Originally Posted by bsquared I believe I see a fairly easy way to implement what you want but I don't have time right now to do it. Here is a sketch (for you, if you have the interest and some C coding skills and can compile yafu, or for me, for future reference). In driver.c, in the applyOpt function, case 58 (near line 2315), allow for a user to input the string "light", "normal", or "deep" (the plan options), in addition to the usual numeric input. "custom" could probably also be accommodated by allowing the input of a number less than 1. In factor_common.c, function init_factor_work, just before the if/else branching near line 2030, check to see if initial_work is equal to whatever special values were selected for that purpose in applyOpt, if the plan strings were input. init_factor_work knows the size of the current input, so initial_work could be changed at that point to the value that would have been the final result of the indicated plan. Example: "-work light" would put the value -1 (or whatever) into autofact_obj.initial_work. init_factor_work would then see that initial_work == -1, and change it to be autofact_obj.initial_work = 2/9 * size(input) The rest of the code proceeds as normal. if initial work is a number between 0 and 1, use that as an indication of a custom plan. Work levels between 0 or 1 would not otherwise ever occur, so that should be ok.
Actually, your original request is even easier than that. Just need the re-interpretation of a number between 0 and 1 as the "work_fraction" that you asked for. Then, nothing needs to happen in driver.c. You just need something like this prior to the if/else branching in init_factor_work:

if (autofact_obj.initial_work < 1.0)
autofact_obj.initial_work = autofact_obj.initial_work * fobj->digits

 2018-10-03, 16:16 #6 bsquared     "Ben" Feb 2007 1110001000012 Posts Well, it was slightly harder than I first thought. Just-updated SVN 376 in branches/wip has this new functionality. Code: + interpret values less than 1.0 to command line option -work to mean a scaling of the input number (tested to work with single and batchfile inputs)
 2018-10-04, 09:25 #7 ricky   May 2018 43 Posts Thank you!
2018-10-04, 10:29   #8
LaurV
Romulan Interpreter

"name field"
Jun 2011
Thailand

996310 Posts

Quote:
 Originally Posted by ricky Thank you, this is probably the most reasonable thing to do. What I wanted was something like doing -plan light once for all numbers in a batch file, and then switching to plan normal for the remaining numbers, but of course without redoing what I've already done.
Isn't that the same as just doing plan=normal, and avoid all the headache, as long as ecm exits when a factor is found? Sorry but I still do not get it where is the advantage.

 Similar Threads Thread Thread Starter Forum Replies Last Post Yamato Puzzles 8 2013-05-16 15:50 stars10250 Hardware 5 2012-02-19 18:32 Raman Math 7 2009-02-27 18:01 tinhnho Miscellaneous Math 4 2005-01-17 19:45 Cyclamen Persicum Miscellaneous Math 9 2003-04-13 14:56

All times are UTC. The time now is 14:42.

Fri May 27 14:42:41 UTC 2022 up 43 days, 12:44, 1 user, load averages: 1.52, 1.60, 1.60