Why does yafu remove entry from batchfile when i manually interrupt yafu wuth ctrl+c?

[QUOTE=kotenok2000;611135]Why does yafu remove entry from batchfile when i manually interrupt yafu wuth ctrl+c?[/QUOTE]

It removes lines after they are completed... it doesn't check that they were completed successfully.

I've always been on the fence about whether it should remove lines at all... on the one hand it's nice to know where you are in the process if something gets interrupted (e.g., power outage, in which case the line wouldn't be removed). On the other there are situations like this that are difficult to handle.

Since I don't want to deal with difficult situations I will probably just get rid of the removing-lines-as-they-finish feature unless there are strong opinions about keeping it.

[QUOTE=bsquared;611129]That said, I'm not sure how you are getting both compressed and uncompressed relations in a single file.[/QUOTE]
I don't. They are all compressed. But the machines run other things too, and in a not very stable environment, and the relations files get HUUGE. Sometimes a chunk inside of such a file is damaged, and yafu/gzip can not go behind of it. In a not-compressed file the things would be as easy as deleting few lines of text, with a text editor that can open such large files, or sometimes, not even that, because yafu will just skip lines with the bad relations. Also, when the computer crashes and rels0, rels1, ... rels_n (which are always uncompressed) remain hanging, on a not-compressed environment I could concatenate all these files to the rels.dat with a simple DOS copy command, and salvage the relations, before resuming the sieving. That is why my pledge for a non-compressed dat file. With a compressed dat file, I can not do any of those, and editing the file when things crash is more tedious (as explained in the previous post, something the "normal" user, who doesn't eat hex and binary for breakfast as we eat, can not do). The only disadvantage of an uncompressed dat file would be the larger size, and a bit longer time to read the relations when filtering (the relations are read from disk, as opposite to the zipped file which is decompressed in ram, faster), but nowadays everybody has large disks with lots of free space, and the additional 5-10 minutes, 3 or 4 times per day, won't be an issue.

I am using executable yafu, not compiled by myself. Which compressed the relations. I remember now that you told me once about recompiling msieve, but that I never did...

[ATTACH]27182[/ATTACH]

[QUOTE=bsquared;611137]I will probably just get rid of the removing-lines-as-they-finish feature unless there are strong opinions about keeping it.[/QUOTE]I have a strong preference to keep it for my own use. If you want to disable that by default then please leave the code in there behind a [c]--auto-remove-batch-lines[/c] or similar switch, please.

To recover data from a damaged .gz file try gzrecover. My script to recover from rubbish in relations from NFS@Home uses:
[code]
gzrecover -p $GZ | remdups 1250 -v >$DAT
[/code]

$GZ is file to process.
$DAT is where to put the recovered relations.

Just ran into something in today's v2.09 that I haven't seen before:[code]=== Starting work on batchfile expression ===
factor(9893910732172879371097056787104792163954805874908431656489378038530926857)
=============================================
fac: factoring 9893910732172879371097056787104792163954805874908431656489378038530926857
fac: using pretesting plan: deep
fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 75 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C73
rho: x^2 + 2, starting 1000 iterations on C73
rho: x^2 + 1, starting 1000 iterations on C73
pm1: starting B1 = 150K, B2 = gmp-ecm default on C73
ecm: 30/30 curves on C73, B1=2k, B2=gmp-ecm default
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
could not open factor.log for appending
ecm: ECM executable does not exist at C:\Users\User\Desktop\yafu2\ecm\ecm.exe
ecm: using internal single threaded ECM...
ecm: 74/74 curves on C73, B1=11k, B2=gmp-ecm default
fopen error: Too many open files
<loop ad infinitum>[/code]and it kept looping until I cancelled it.
(The ECM executable does exist there, I think it just couldn't open it due to too many open files. And of course [c]factor.log[/c] does exist.)
I would suggest that "too many open files" should be a fatal error and YAFU should simply exit at that point rather than looping.
The screen output would just keep overwriting the [c]ecm: xx/74 curves on C73[/c] line over and over, however factor.log seemed to contain a full/normal run log for repeated factoring:[code]08/10/22 17:07:55, ****************************
08/10/22 17:07:55, Starting factorization of 9893910732172879371097056787104792163954805874908431656489378038530926857
08/10/22 17:07:55, using pretesting plan: deep
08/10/22 17:07:55, using specified qs/gnfs crossover of 100 digits
08/10/22 17:07:55, using specified qs/snfs crossover of 75 digits
08/10/22 17:07:55, ****************************
08/10/22 17:07:55, rho: x^2 + 3, starting 1000 iterations on C73
08/10/22 17:07:55, rho: x^2 + 2, starting 1000 iterations on C73
08/10/22 17:07:55, rho: x^2 + 1, starting 1000 iterations on C73
08/10/22 17:07:55, pm1: starting B1 = 150K, B2 = gmp-ecm default on C73
08/10/22 17:07:55, current ECM pretesting depth: 0.000000
08/10/22 17:07:55, scheduled 30 curves at B1=2000 toward target pretesting depth of 24.333333
08/10/22 17:07:55, Finished 30 curves using GMP-ECM method on C73 input, B1=2k, B2=gmp-ecm default
08/10/22 17:07:55, current ECM pretesting depth: 15.177725
08/10/22 17:07:55, scheduled 74 curves at B1=11000 toward target pretesting depth of 24.333333
08/10/22 17:07:56, Finished 74 curves using GMP-ECM method on C73 input, B1=11k, B2=gmp-ecm default
08/10/22 17:07:56, current ECM pretesting depth: 20.242996
08/10/22 17:07:56, scheduled 176 curves at B1=50000 toward target pretesting depth of 24.333333
08/10/22 17:08:00, Finished 176 curves using GMP-ECM method on C73 input, B1=50k, B2=gmp-ecm default
08/10/22 17:08:00, final ECM pretested depth: 24.355146
08/10/22 17:08:00, scheduler: switching to sieve method
08/10/22 17:08:00, starting SIQS on c73: 9893910732172879371097056787104792163954805874908431656489378038530926857
08/10/22 17:08:00, random seed: 10805957936155471635
08/10/22 17:08:00, ==== sieve params ====
08/10/22 17:08:00, n = 76 digits, 251 bits
08/10/22 17:08:00, factor base: 21952 primes (max prime = 527987)
08/10/22 17:08:00, single large prime cutoff: 44878895 (85 * pmax)
08/10/22 17:08:00, double large prime range from 278770272169 to 24607855715335
08/10/22 17:08:00, DLP MFB = 1.75
08/10/22 17:08:00, allocating 6 large prime slices of factor base
08/10/22 17:08:00, buckets hold 2048 elements
08/10/22 17:08:00, large prime hashtables have 491520 bytes
08/10/22 17:08:00, using AVX2 enabled 32k sieve core
08/10/22 17:08:00, sieve interval: 5 blocks of size 32768
08/10/22 17:08:00, polynomial A has ~ 9 factors
08/10/22 17:08:00, using multiplier of 233
08/10/22 17:08:00, using multiplier of 233
08/10/22 17:08:00, using Q2(x) polynomials for kN mod 8 = 1
08/10/22 17:08:00, using SPV correction of 21 bits, starting at offset 34
08/10/22 17:08:00, trial factoring cutoff at 81 bits
08/10/22 17:08:00, ==== sieving started ( 4 threads) ====
08/10/22 17:08:08, trial division touched 2830496 sieve locations out of 15199764480
08/10/22 17:08:08, total reports = 2830496, total surviving reports = 1092798
08/10/22 17:08:08, total blocks sieved = 463860, avg surviving reports per block = 2.36
08/10/22 17:08:08, dlp-ecm: 0 failures, 54248 attempts, 572102 outside range, 359414 prp, 53453 useful
08/10/22 17:08:08, 22363 relations found: 9439 full + 12924 from 151048 partial, using 46386 polys (333 A polys)
08/10/22 17:08:08, on average, sieving found 3.46 rels/poly and 20068.37 rels/sec
08/10/22 17:08:08, trial division touched 2830496 sieve locations out of 15199764480
08/10/22 17:08:08, ==== post processing stage (msieve-1.38) ====
08/10/22 17:08:08, QS elapsed time = 7.9990 seconds.
08/10/22 17:08:08, begin singleton removal with 160487 relations
08/10/22 17:08:08, reduce to 38458 relations in 7 passes
08/10/22 17:08:08, recovered 38458 relations
08/10/22 17:08:08, recovered 26065 polynomials
08/10/22 17:08:08, attempting to build 22363 cycles
08/10/22 17:08:08, found 22363 cycles from 38458 relations in 3 passes
08/10/22 17:08:08, distribution of cycle lengths:
08/10/22 17:08:08, length 1 : 9439
08/10/22 17:08:08, length 2 : 7879
08/10/22 17:08:08, length 3 : 3353
08/10/22 17:08:08, length 4 : 1161
08/10/22 17:08:08, length 5 : 383
08/10/22 17:08:08, length 6 : 106
08/10/22 17:08:08, length 7 : 28
08/10/22 17:08:08, length 9+: 14
08/10/22 17:08:08, largest cycle: 10 relations
08/10/22 17:08:08, matrix is 21952 x 22363 (3.6 MB) with weight 758624 (33.92/col)
08/10/22 17:08:08, sparse part has weight 758624 (33.92/col)
08/10/22 17:08:08, filtering completed in 3 passes
08/10/22 17:08:08, matrix is 17396 x 17460 (2.9 MB) with weight 619158 (35.46/col)
08/10/22 17:08:08, sparse part has weight 619158 (35.46/col)
08/10/22 17:08:08, saving the first 48 matrix rows for later
08/10/22 17:08:09, matrix is 17348 x 17460 (2.4 MB) with weight 510149 (29.22/col)
08/10/22 17:08:09, sparse part has weight 461081 (26.41/col)
08/10/22 17:08:09, matrix includes 64 packed rows
08/10/22 17:08:09, commencing Lanczos iteration
08/10/22 17:08:09, memory use: 3.1 MB
08/10/22 17:08:10, lanczos halted after 276 iterations (dim = 17348)
08/10/22 17:08:10, recovered 17 nontrivial dependencies
08/10/22 17:08:10, prp40 = 1360456298247937862016941462358767177779
08/10/22 17:08:10, prp34 = 7272494342460497523675029892412883
08/10/22 17:08:10, Lanczos elapsed time = 2.0160 seconds.
08/10/22 17:08:10, Sqrt elapsed time = 0.0110 seconds.
08/10/22 17:08:10, SIQS elapsed time = 10.0265 seconds.
08/10/22 17:08:10,
08/10/22 17:08:10,
08/10/22 17:08:10, Total factoring time = 15.4097 seconds[/code]And factor.json also contains multiple entries, however I found it unexpected that it seems to alternate the order of the found factors:[code]{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["1360456298247937862016941462358767177779","7272494342460497523675029892412883"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":14.9000, "ecm":3.7169, "pm1":0.0352, "pp1":0.0000, "siqs":10.3100, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:06:52", "time-end" : "2022-08-10 17:07:07", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }
{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["7272494342460497523675029892412883","1360456298247937862016941462358767177779"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":14.2596, "ecm":4.0419, "pm1":0.0347, "pp1":0.0000, "siqs":9.3449, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:07:07", "time-end" : "2022-08-10 17:07:21", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }
{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["1360456298247937862016941462358767177779","7272494342460497523675029892412883"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":16.6600, "ecm":4.5211, "pm1":0.0445, "pp1":0.0000, "siqs":10.7723, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:07:21", "time-end" : "2022-08-10 17:07:38", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }
{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["7272494342460497523675029892412883","1360456298247937862016941462358767177779"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":16.7173, "ecm":5.0581, "pm1":0.0360, "pp1":0.0000, "siqs":10.4897, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:07:38", "time-end" : "2022-08-10 17:07:55", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }
{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["1360456298247937862016941462358767177779","7272494342460497523675029892412883"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":15.4097, "ecm":4.5138, "pm1":0.0402, "pp1":0.0000, "siqs":10.0265, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:07:55", "time-end" : "2022-08-10 17:08:10", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }
{ "input-expression":"factor(9893910732172879371097056787104792163954805874908431656489378038530926857)", "input-decimal":"9893910732172879371097056787104792163954805874908431656489378038530926857", "input-argument-string":"factor(@) -batchfile random_composites.txt ", "factors-prime":["7272494342460497523675029892412883","1360456298247937862016941462358767177779"], "pm1-curves" : {"150000":1}, "ecm-curves" : {"2000":30,"11000":74,"50000":176}, "ecm-levels" : {"t15":32.31,"t20":9.42,"t25":0.87,"t30":0.06}, "runtime" : {"total":14.0025, "ecm":3.7470, "pm1":0.0336, "pp1":0.0000, "siqs":9.3725, "nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000}, "time-start" : "2022-08-10 17:08:10", "time-end" : "2022-08-10 17:08:24", "info":{"compiler":"MSVC 1931","ECM-version":"7.0.4","MPIR-version":"3.0.0","yafu-version":"2.09"} }[/code]Of course the too many open files might be Windows misbehaving rather than YAFU (some update was trying to apply itself in the background at the time I noticed the YAFU problem by chance), but if the error is detected it should exit rather than loop.

How many entries does your batchfile have? I'm wondering if something isn't getting closed properly when looping over batchfile entries.

[QUOTE=bsquared;611176]How many entries does your batchfile have? I'm wondering if something isn't getting closed properly when looping over batchfile entries.[/QUOTE]I process batches of 100 at a time, submit results, fetch new, re-launch YAFU against the next batch.

I've done this successfully for long periods with v1.34.5 but only just started this on YAFU 2.09 today because the [c]-batchfile[/c] option was broken until this morning.

I'm not fully convinced that it's a YAFU-error rather than a Windows-error, just that YAFU's handling of the error condition should be better.

[QUOTE=James Heinrich;611177]I process batches of 100 at a time, submit results, fetch new, re-launch YAFU against the next batch.

I've done this successfully for long periods with v1.34.5 but only just started this on YAFU 2.09 today because the [c]-batchfile[/c] option was broken until this morning.

I'm not fully convinced that it's a YAFU-error rather than a Windows-error, just that YAFU's handling of the error condition should be better.[/QUOTE]

I've just done some tests with larger batch files and I'm having problems too. There is some kind of memory or file descriptor leak somewhere that I'll have to track down. Sorry about that! Smaller batches seem to work... which of course doesn't fix the problem but might be a work around for now.

[QUOTE=bsquared;611181]Smaller batches seem to work...[/QUOTE]I've always done batch of 100. I've completed 14x 100 since restarting after posting my bug report and it's been going fine (so far).

After some longer tests, I've checked in a few fixes and added some missing traps for file open errors. The .exe is updated. Long batchfiles are working fine for me now too.

It had been running fine with 100-batches for about 16h, but I've switched to the new build.

If I may repeat a request in the JSON output, would it be possible to add a [c]sum[/c] key in addition the the [c]tXX[/c] keys? I know we can calculate it ourselves, but it's easier if it's just there.

Also, perhaps for more-compact output the not-used values could be omitted -- for example if P+1, NFS, etc wasn't run there's no need to output the zero values: [c]"pp1":0.0000[/c], [c]"nfs-total":0.0000, "nfs-poly":0.0000, "nfs-sieve":0.0000, "nfs-filter":0.0000, "nfs-la":0.0000, "nfs-sqrt":0.0000[/c]. That's the beauty of JSON -- fields can be added or omitted without breaking the output.

Quick question: Can YAFU pass on GPU use for Msieve calls. I'm not seeing it in the docs. I thought I had in the past.

[QUOTE=bsquared;611133]Checked in new update and new windows exe:

+ by default json output is now all on one line, -jsonpretty option to pretty print like before (each category on separate line)[/QUOTE]

How do I put that jsonpretty option into yafu.ini? When I just put the word on a line by itself (as with similar options in the sample yafu.ini) it seems to be ignored. I've checked and I haven't misspelt it.

Try "jsonpretty=1". I've noticed that for a given flag that putting the flag name, followed by "=1" (i.e. v=1) works.

[QUOTE=Stargate38;611580]Try "jsonpretty=1". I've noticed that for a given flag that putting the flag name, followed by "=1" (i.e. v=1) works.[/QUOTE]

No, sorry, that doesn't work.

For me, either of the following work in yafu.ini:
[CODE]jsonpretty
jsonpretty=1[/CODE]

Things to check:
1) make sure you have the latest .exe. I updated the executable without tweaking the version number, so you'd have needed to re-download it.
2) If the statement is the last line of the file, make sure it has a newline/carriage return.
3) I have only tested on linux and windows. I have no idea how something different could change the results but stranger things have happened.

[QUOTE=EdH;611283]Quick question: Can YAFU pass on GPU use for Msieve calls. I'm not seeing it in the docs. I thought I had in the past.[/QUOTE]

It doesn't have the ability to pass on user-input arguments to msieve as strings. If the gpu can be used without any special argument strings, and you build msieve-gpu and link it into yafu like normal, then I suppose it would work. Otherwise you'd have to modify the source.

I have only rarely used msieve-gpu... if you can provide me the special argument strings needed (if any) then I can maybe add an option to use it. Also if using the gpu changes other things like norms or min_e.

[QUOTE=bsquared;611635]It doesn't have the ability to pass on user-input arguments to msieve as strings. If the gpu can be used without any special argument strings, and you build msieve-gpu and link it into yafu like normal, then I suppose it would work. Otherwise you'd have to modify the source.

I have only rarely used msieve-gpu... if you can provide me the special argument strings needed (if any) then I can maybe add an option to use it. Also if using the gpu changes other things like norms or min_e.[/QUOTE]Thanks! I think just adding [C]-g 0[/C] to the msieve call should work, but I'll play and get back with you. I just wanted to make sure it wasn't already there and I was missing it. (Maybe there's a way to have msieve default to GPU if available...)

Can you tell me why doesn't siqs output show on screen when using this perl script?

[CODE]==== sieving in progress (8 threads): 101408 relations needed ====
==== Press ctrl-c to abort and save state ====
2789 rels found: 2583 full + 206 from 172505 partial, (9836.93 rels/sec)))[/CODE]

When running through ali.pl i only see this:
[CODE]==== sieving in progress (8 threads): 101408 relations needed ====
==== Press ctrl-c to abort and save state ====[/CODE]

It looks like if I compile Msieve with CUDA support, it doesn't make its way into YAFU. I get CUDA errors. I would have to run down everything one-by-one, which I can't currently see myself doing real soon. I might play at it again at some point, but not for now.

Thanks for all.

[QUOTE=James Heinrich;610801]I wrote a PHP script to convert [c]factor.log[/c] to [c]factor.json[/c][/QUOTE]In case it's useful to anyone else, I wrote a small PHP script to convert [c]factor.json[/c] to simple [c]composite=factor1*factor2[/c] style for submission to factordb.com (which doesn't currently support the new YAFU factor.json format).[code]<?php
// parse YAFU factor.json lines into COMPOSITE=FACTOR*FACTOR result lines for factordb.com

if ((count($_SERVER['argv']) != 2) || !preg_match('#\\.json$#i', $_SERVER['argv'][1])) {
echo 'Usage: php '.basename(__FILE__).' factor.json'."\n";
} elseif (!file_exists($_SERVER['argv'][1])) {
echo $_SERVER['argv'][1].' does not exist'."\n";
}

$result_lines = '';
foreach (explode("\n", file_get_contents($_SERVER['argv'][1])) as $linecounter => $line) {
if ($line = trim($line)) {
if ((substr($line, 0, 1) == '{') && (substr($line, -1, 1) == '}')) {
if ($JSON = json_decode($line, true)) {
$result_lines .= $JSON['input-decimal'].'='.implode('*', $JSON['factors-prime']).(!empty($JSON['factors-composite']) ? '*'.implode('*', $JSON['factors-composite']) : '')."\n";
} else {
echo 'error '.__LINE__.': json_decode() failed on line '.($linecounter + 1).' of '.$json_filename.':'."\n".$line."\n\n"; exit(1);
}
} else {
echo 'error '.__LINE__.': unexpected line '.($linecounter + 1).' in '.$json_filename.':'."\n".$line."\n\n"; exit(1);
}
}
}
echo $result_lines."\n";[/code]

[QUOTE=kotenok2000;611643]Can you tell me why doesn't siqs output show on screen when using this perl script?
[/QUOTE]

From ali.pl.txt:
[code]
open(YAFU, "./yafu \"factor($composite)\" -threads $yafuthreads|") or die "Couldn't start yafu!";
while (<YAFU>) {
print "$_";
[/code]

AFAIK output from yafu get's buffered somewhere, it will only be passed to your script when yafu has output a complete line. But the progress will be output by yafu as some text, without a newline, then control chars to get back to the start of the *same* line on screen. So your script won't get anything to print until yafu has finished sieving.

I don't know any way round this though.

But gnfs output is displayed correctly.
Maybe some output is send to stderr and some to stdout and perl relays only stdout?

gnfs output contains newlines.

siqs progress output does not... only carriage returns (\r)

Can yafu be modified so siqs output also contains newlines?

[QUOTE=kotenok2000;611702]Can yafu be modified so siqs output also contains newlines?[/QUOTE]You can modify the YAFU code, but your output would scroll everything continuously. I don't have time to search right now, but there is a way to empty the buffer periodically with either Python or Perl. I don't remember which I was working with for that at the time. That is where you should look for a solution. If I can, I'll try to find more info later. I'm kind of tied up right now.

Another option you might consider is calling YAFU via a system call rather than a Perl call. That should give you the standard YAFU output. You may need to handle the results a bit differently, though.

ETA: You could look at "Perl STDOUT->autoflush(1)" to see if it might help.

Does yafu 2 still support old cpus without avx?

Your best option is probably to call yafu as [c]system("./yafu \"factor($composite)\" -threads $yafuthreads -logfile yafu.log");[/c], then parse yafu.log to find the factors once it has finished. Then delete yafu.log etc to tidy up. That's basically what my scripts to factor small composites in factordb do.

[QUOTE=bsquared;611633]For me, either of the following work in yafu.ini:
[CODE]jsonpretty
jsonpretty=1[/CODE]

Things to check:
1) make sure you have the latest .exe. I updated the executable without tweaking the version number, so you'd have needed to re-download it.
2) If the statement is the last line of the file, make sure it has a newline/carriage return.
3) I have only tested on linux and windows. I have no idea how something different could change the results but stranger things have happened.[/QUOTE]

I have the latest .exe: if I put -jsonpretty on the command line it works.
The statement is not the last line of the .ini file.
I'm using windows.

[Edited at quarter past midnight.]
Because I'm running this by means of a system call from another program, the yafu.ini I need to amend is the one in the other program's home directory and not the one in yafu-2.09. As soon as I add jsonpretty to that file, all works as it should.

How can I tell yafu-2.09 to use its own yafu.ini file instead of the yafu.ini file in the current directory?

According to the source code, it always chooses the yafu.ini in the working directory. There are three ways to solve this:
1. cd to the yafu directory before running it
2. Copy the default yafu.ini to your directory
3. Change the source code to always find yafu.ini in your directory
To be exact, you can change the path in top/driver.c Line 110
ini_success = readINI("yafu.ini", options);

Sometimes yafu gets stuck siqs sieving on repeat and I have to kill yafu.exe
It reports

[CODE]08/27/22 01:31:03, trial division touched 0 sieve locations out of 0
08/27/22 01:31:03, total reports = 0, total surviving reports = 0
08/27/22 01:31:03, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
08/27/22 01:31:03, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful[/CODE]
I use fdb_comp_evaluator.pl from [URL="https://github.com/AntonioPK/Fdb"]https://github.com/AntonioPK/Fdb[/URL]

Another member asked me to test a failure and I can replicate it with both 2.07 and 2.09. The composite is 9649340769776349618630915417390658987772498722136713669954798667326094136661 and it has the short form (8^85-2)/6 per factordb:[code]YAFU Version 2.09
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991
Parsed yafu.ini from /home/math96/Math/yafu

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> factor(9649340769776349618630915417390658987772498722136713669954798667326094136661)
fac: factoring 9649340769776349618630915417390658987772498722136713669954798667326094136661
fac: using pretesting plan: normal
fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 75 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C76
rho: x^2 + 2, starting 1000 iterations on C76
rho: x^2 + 1, starting 1000 iterations on C76
nfs: searching for brent special forms...
nfs: input divides 2^254 - 1
nfs: snfs form detection took 0.000103 seconds
nfs: snfs form detection took 0.000061 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727
fac: ecm effort reduced from 23.38 to 18.19: input has snfs form
pm1: starting B1 = 150K, B2 = gmp-ecm default on C76
nfs: snfs form detection took 0.000109 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727
fac: ecm effort reduced from 23.38 to 18.19: input has snfs form
ecm: 30/30 curves on C76, B1=2k, B2=gmp-ecm default
nfs: snfs form detection took 0.000069 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727
fac: ecm effort reduced from 23.38 to 18.19: input has snfs form
ecm: 45/45 curves on C76, B1=11k, B2=gmp-ecm default
nfs: snfs form detection took 0.000073 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727
fac: ecm effort reduced from 23.38 to 18.19: input has snfs form
nfs: commencing nfs on c76: 9649340769776349618630915417390658987772498722136713669954798667326094136661
nfs: searching for brent special forms...
nfs: input divides 2^254 - 1
nfs: snfs form detection took 0.000091 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727
nfs: found 4 polynomials, selecting best
nfs: using provided snfs difficulty 38.230809
nfs: using provided snfs difficulty 38.531839
nfs: using provided snfs difficulty 38.230809
nfs: commencing algebraic side lattice sieving over range: 155000 - 160000
nfs: commencing algebraic side lattice sieving over range: 180000 - 185000
nfs: commencing algebraic side lattice sieving over range: 160000 - 165000
nfs: commencing algebraic side lattice sieving over range: 170000 - 175000
nfs: commencing algebraic side lattice sieving over range: 150000 - 155000
nfs: commencing algebraic side lattice sieving over range: 175000 - 180000
nfs: commencing algebraic side lattice sieving over range: 165000 - 170000
nfs: commencing algebraic side lattice sieving over range: 185000 - 190000
*** Error in `../ggnfs/bin/gnfs-lasieve4I11e': realloc(): invalid next size: 0x00000000010b52f0 ***
======= Backtrace: =========
[0x47fc21]
[0x48b166]
[0x48c489]
[0x40bb25]
[0x40acf9]
[0x406167]
[0x467ba6]
[0x467d9a]
[0x4083f9]
======= Memory map: ========
00400000-0055e000 r-xp 00000000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
0075d000-00760000 rwxp 0015d000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
00760000-007f5000 rwxp 00000000 00:00 0
00d3d000-01355000 rwxp 00000000 00:00 0 [heap]
7f37dc000000-7f37dc024000 rwxp 00000000 00:00 0
7f37dc024000-7f37e0000000 ---p 00000000 00:00 0
7f37e1f5f000-7f37e45a2000 rwxp 00000000 00:00 0
7fff9ca0d000-7fff9ca2e000 rwxp 00000000 00:00 0 [stack]
7fff9cad1000-7fff9cad4000 r--p 00000000 00:00 0 [vvar]
7fff9cad4000-7fff9cad5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
*** Error in `../ggnfs/bin/gnfs-lasieve4I11e': realloc(): invalid next size: 0x0000000002672610 ***
======= Backtrace: =========
[0x47fc21]
[0x48b166]
[0x48c489]
[0x40bb25]
[0x40acf9]
[0x406167]
[0x467ba6]
[0x467d9a]
[0x4083f9]
======= Memory map: ========
00400000-0055e000 r-xp 00000000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
0075d000-00760000 rwxp 0015d000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
00760000-007f5000 rwxp 00000000 00:00 0
022f8000-02913000 rwxp 00000000 00:00 0 [heap]
7f8240000000-7f8240024000 rwxp 00000000 00:00 0
7f8240024000-7f8244000000 ---p 00000000 00:00 0
7f8245874000-7f8247ec1000 rwxp 00000000 00:00 0
7ffcaa002000-7ffcaa023000 rwxp 00000000 00:00 0 [stack]
7ffcaa1b7000-7ffcaa1ba000 r--p 00000000 00:00 0 [vvar]
7ffcaa1ba000-7ffcaa1bb000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
Aborted (core dumped)
*** Error in `../ggnfs/bin/gnfs-lasieve4I11e': realloc(): invalid next size: 0x0000000001c42f20 ***
======= Backtrace: =========
[0x47fc21]
[0x48b166]
[0x48c489]
[0x40bb25]
[0x40acf9]
[0x406167]
[0x467ba6]
[0x467d9a]
[0x4083f9]
======= Memory map: ========
00400000-0055e000 r-xp 00000000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
0075d000-00760000 rwxp 0015d000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
00760000-007f5000 rwxp 00000000 00:00 0
01853000-01f59000 rwxp 00000000 00:00 0 [heap]
7f4d38000000-7f4d38024000 rwxp 00000000 00:00 0
7f4d38024000-7f4d3c000000 ---p 00000000 00:00 0
7f4d3c1b3000-7f4d3e7ec000 rwxp 00000000 00:00 0
7ffc33d13000-7ffc33d34000 rwxp 00000000 00:00 0 [stack]
7ffc33d82000-7ffc33d85000 r--p 00000000 00:00 0 [vvar]
7ffc33d85000-7ffc33d86000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
*** Error in `../ggnfs/bin/gnfs-lasieve4I11e': realloc(): invalid next size: 0x0000000001960e50 ***
======= Backtrace: =========
[0x47fc21]
[0x48b166]
[0x48c489]
[0x40bb25]
[0x40acf9]
[0x406167]
[0x467ba6]
[0x467d9a]
[0x4083f9]
======= Memory map: ========
00400000-0055e000 r-xp 00000000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
0075d000-00760000 rwxp 0015d000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
00760000-007f5000 rwxp 00000000 00:00 0
01431000-01b71000 rwxp 00000000 00:00 0 [heap]
7ff054000000-7ff054024000 rwxp 00000000 00:00 0
7ff054024000-7ff058000000 ---p 00000000 00:00 0
7ff05ae9a000-7ff05d4b4000 rwxp 00000000 00:00 0
7ffc503c6000-7ffc503e7000 rwxp 00000000 00:00 0 [stack]
7ffc503ef000-7ffc503f2000 r--p 00000000 00:00 0 [vvar]
7ffc503f2000-7ffc503f3000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
Aborted (core dumped)
*** Error in `../ggnfs/bin/gnfs-lasieve4I11e': realloc(): invalid next size: 0x00000000021c9770 ***
======= Backtrace: =========
[0x47fc21]
[0x48b166]
[0x48c489]
[0x40bb25]
[0x40acf9]
[0x406167]
[0x467ba6]
[0x467d9a]
[0x4083f9]
======= Memory map: ========
00400000-0055e000 r-xp 00000000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
0075d000-00760000 rwxp 0015d000 08:01 6693409 /home/math96/Math/ggnfs/bin/gnfs-lasieve4I11e
00760000-007f5000 rwxp 00000000 00:00 0
01b3b000-02488000 rwxp 00000000 00:00 0 [heap]
7f2928000000-7f2928024000 rwxp 00000000 00:00 0
7f2928024000-7f292c000000 ---p 00000000 00:00 0
7f292e8cb000-7f2930f21000 rwxp 00000000 00:00 0
7fff6ad49000-7fff6ad6a000 rwxp 00000000 00:00 0 [stack]
7fff6ad8e000-7fff6ad91000 r--p 00000000 00:00 0 [vvar]
7fff6ad91000-7fff6ad92000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
total yield: 169943, q=160031 (0.00002 sec/rel)
total yield: 179959, q=150193 (0.00002 sec/rel)
total yield: 171864, q=165049 (0.00002 sec/rel)


***factors found***


***co-factor***
C76 = 9649340769776349618630915417390658987772498722136713669954798667326094136661[/code]Due to residual files, subsequent runs provide one factor, but not both:[code]
YAFU Version 2.09
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991
Parsed yafu.ini from /home/math96/Math/yafu

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> factor(9649340769776349618630915417390658987772498722136713669954798667326094136661)
fac: factoring 9649340769776349618630915417390658987772498722136713669954798667326094136661
fac: using pretesting plan: normal
fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 75 digits
nfs: searching for brent special forms...
nfs: input divides 2^254 - 1
nfs: snfs form detection took 0.000082 seconds

starting SIQS on c39: 170141183460469231731687303715884105727
Total factoring time = 0.1513 seconds


***factors found***

P39 = 170141183460469231731687303715884105727

ans = 1[/code]I tested the siever that was reported faulty (with a separate test poly) and it ran fine.

Thanks for all your work.

[QUOTE=EdH;612233]Another member asked me to test a failure and I can replicate it with both 2.07 and 2.09[/QUOTE]For what it's worth, it works fine on v1.34.5:[code]Starting factorization of 9649340769776349618630915417390658987772498722136713669954798667326094136661
starting SIQS on c76: 9649340769776349618630915417390658987772498722136713669954798667326094136661
commencing Lanczos iteration
memory use: 2.5 MB
lanczos halted after 344 iterations (dim = 21633)
recovered 16 nontrivial dependencies
prp39 = 170141183460469231731687303715884105727
prp38 = 56713727820156410577229101238628035243
Lanczos elapsed time = 1.2290 seconds.
Sqrt elapsed time = 0.0180 seconds.
SIQS elapsed time = 10.4296 seconds.
Total factoring time = 22.3813 seconds[/code]

Maybe you compiled gnfs incorrectly?
What if you copy gnfs-lasieve files from yafu boinc project slot directory?
They have linux compiled executables. [url]https://yafu.myfirewall.org/yafu/apps.php[/url]

[QUOTE=James Heinrich;612236]For what it's worth, it works fine on v1.34.5:[/QUOTE]Thanks! I hadn't tried version 1.
[QUOTE=kotenok2000;612237]Maybe you compiled gnfs incorrectly?. . .[/QUOTE]Thanks, but it also fails with the siever that bsquared compiled.

(8^85-2)/6 simplifies to (2^254-1)/3 which factors to (2^127-1)*(2^127+1)/3.

The problem was probably caused by the fact the expression had algebraic factors.

If you look closely at EdH's post of the output you'll see:

[CODE]nfs: commencing nfs on c76: 9649340769776349618630915417390658987772498722136713669954798667326094136661
nfs: searching for brent special forms...
nfs: input divides 2^254 - 1
nfs: snfs form detection took 0.000091 seconds
gen: found primitive cofactor < input number:
gen: 170141183460469231731687303715884105727[/CODE]

Which shows that it recognizes the form 2^254-1 and that it found the algebraic factor (2^127-1). What I guess I hadn't anticipated is that this would complete the factorization. I can patch that up. The ggnfs sievers must have issues when asked to factor a small prime number, or the parameters are crazy because the input (a p38) is so small.

1.34.5 works because the siqs/snfs crossovers are apparently set differently so it proceeds immediately to siqs without doing the algebraic factor detection.

In yafu.ini from git, there is no B1pp1 nor B1pp2, but the B1pm1 and B1pm2 appear two times.

Intentional, or copy/paste error?

For some reason, the latest release of YAFU will run on my i7 system, but not a Xeon I have. Both Windows 10 and 16 GB of RAM.

It displays its title screen and some other info then drops back to the command prompt. No error messages. :confused:

[QUOTE=storm5510;612806]i7 system, but not a Xeon I have[/QUOTE]"i7" and "Xeon" are both nebulous descriptors that could describe any number of CPUs over decades. Perhaps specific model numbers would provide more of a clue as to perhaps which features are not supported on your "Xeon".

[QUOTE=James Heinrich;612807]"i7" and "Xeon" are both nebulous descriptors that could describe any number of CPUs over decades. Perhaps specific model numbers would provide more of a clue as to perhaps which features are not supported on your "Xeon".[/QUOTE]

E5-1620 Sandy Bridge EP.

Version 1.34.5 runs without issues. Nothing later will.

[url]https://www.cpu-world.com/CPUs/Xeon/Intel-Xeon%20E5-1620.html[/url]
Maybe it requires avx2?

It should work on systems without AVX2, but I don't have any of those to test on anymore, so apparently it doesn't. Based on where it crashes it would seem the problem lies in the ysieve library, since one of the first things yafu does is create and store a small list of primes.

Yes, I have analyzed this before: :smile:

[QUOTE=kruoli;589431]When running the current build on GIT on an Ivy Bridge processor, I get an invalid instruction error (MULX, since Ivy Bridge does not support BMI(2)) at 0x000000013F571B43. This happens when the prompt ([C]>> [/C]) is already displayed. Is the processor too old to be supported out of the box?[/QUOTE]

I know my [url=https://www.cpu-world.com/CPUs/Core_i7/Intel-Core%20i7-3930K.html]i7-3930K[/url] (also Sandy Bridge) doesn't run YAFU 2.x, but I had always assumed that was Windows-7 thing. I guess it's (also?) a hardware thing.

(is it sad that my main daily system is nearing 11 years old? :paul:)

[QUOTE=James Heinrich;612905](is it sad that my main daily system is nearing 11 years old? :paul:)[/QUOTE]

No, I won't give up on my one voluntarily!

[QUOTE=James Heinrich;612905]I know my [url=https://www.cpu-world.com/CPUs/Core_i7/Intel-Core%20i7-3930K.html]i7-3930K[/url] (also Sandy Bridge) doesn't run YAFU 2.x, but I had always assumed that was Windows-7 thing. I guess it's (also?) a hardware thing.

(is it sad that my main daily system is nearing 11 years old? :paul:)[/QUOTE]

Only my i7-7700 is AVX2. The Xeon and i5 are not. These two date back to 2012. The i7 is four years old, (2018). I sourced the parts and built it myself. The Xeon can run Windows 10 or Ubuntu 20.04. I doubt the i5 could run Windows 10. It runs Windows 7 well enough.

My amd fx 6100 ran windows 10

I'm running into the following error while trying to compile the latest YAFU:

[CODE]/usr/bin/ld: ./libysiqs.a(SIQS.o): in function `siqs_static_init':
/home/wombat/yafu/factor/qs/SIQS.c:2309: undefined reference to `nextRoots_32k_avx2_intrin'[/CODE]

Compilation instruction is "make USE_AVX2 NFS=1". Everything else seems to be building properly as the above is the only error.

[QUOTE=wombatman;613736]I'm running into the following error while trying to compile the latest YAFU:

[CODE]/usr/bin/ld: ./libysiqs.a(SIQS.o): in function `siqs_static_init':
/home/wombat/yafu/factor/qs/SIQS.c:2309: undefined reference to `nextRoots_32k_avx2_intrin'[/CODE]

Compilation instruction is "make USE_AVX2 NFS=1". Everything else seems to be building properly as the above is the only error.[/QUOTE]

You'll need to add USE_BMI2=1 to the make line as well. Most cpu's that have avx2 also have bmi2... if yours doesn't then you'll have to remove both the avx2 and bmi2 options.

I sieved an Aliquot C141 using Yafu 2.0 and when the filtering ran, every relation was an error -11. Looking at the .fb file below, somehow Yafu did not include skew, rlim, frmax, famax, srlpmax, or salpmax.

[CODE]N 379940961516713825613865981760557035526784109230555165792877792447392213895676955608876175676740458184733360391979563490370537264576678836483
A0 17921599049871804734714330370707400
A1 884689986849071910726068107020
A2 1004298442072520798460436
A3 -54583391456339434
A4 -93062625051
A5 9180
R0 -2105596592265349121584460471
R1 1152139905935473[/CODE]

I got it to work by adding skew and the other parameters to the .fb file and running Yafu 1. I'm not sure if this was my error or if Yafu 2.0 did not include the parameters for some odd reason.

[QUOTE=richs;617720]I sieved an Aliquot C141 using Yafu 2.0 and when the filtering ran, every relation was an error -11. Looking at the .fb file below, somehow Yafu did not include skew, rlim, frmax, famax, srlpmax, or salpmax.

[CODE]N 379940961516713825613865981760557035526784109230555165792877792447392213895676955608876175676740458184733360391979563490370537264576678836483
A0 17921599049871804734714330370707400
A1 884689986849071910726068107020
A2 1004298442072520798460436
A3 -54583391456339434
A4 -93062625051
A5 9180
R0 -2105596592265349121584460471
R1 1152139905935473[/CODE]


I got it to work by adding skew and the other parameters to the .fb file and running Yafu 1. I'm not sure if this was my error or if Yafu 2.0 did not include the parameters for some odd reason.[/QUOTE]


None of those parameters are needed for filtering, which is the only place .fb files are used. The .job file is where the ggnfs equivalent to those parameters are filled in, for sieving. I don't know why or how filling those parameters in here would cause it to work, or not, for either version. Usually when tons of -11's happen it's because a previous job didn't get cleared out somehow (power loss, job killed, etc.).

I can't factor 27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093
It freezes on commencing Lanczos iteration (8 threads)
memory use: 71.9 MB
with no cpu usage.
yafu "factor(27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093)" -p -threads 8

also it outputs
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.

[QUOTE=kotenok2000;624508]I can't [c]factor(27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093)[/c][/QUOTE][code]factor(27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093)

fac: factoring 27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093
fac: using pretesting plan: deep
fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 100 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C101
rho: x^2 + 2, starting 1000 iterations on C101
rho: x^2 + 1, starting 1000 iterations on C101
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: searching for direct special forms...
nfs: snfs form detection took 0.055005 seconds
nfs: couldn't find special form
pm1: starting B1 = 150K, B2 = gmp-ecm default on C101
ecm: 128/32 curves on C101 @ B1=2000, B2=100*B1
ecm: process took 0.0630 seconds.
ecm: 128/80 curves on C101 @ B1=11000, B2=100*B1
ecm: process took 0.1130 seconds.
ecm: 256/224 curves on C101 @ B1=50000, B2=100*B1
ecm: process took 0.8514 seconds.
pm1: starting B1 = 3750K, B2 = gmp-ecm default on C101
ecm: 512/432 curves on C101 @ B1=250000, B2=100*B1
ecm: process took 7.3860 seconds.
pm1: starting B1 = 15M, B2 = gmp-ecm default on C101
ecm: 640/576 curves on C101 @ B1=1000000, B2=100*B1
ecm: process took 34.6520 seconds.
nfs: commencing nfs on c101: 27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: searching for direct special forms...
nfs: snfs form detection took 0.079990 seconds
nfs: couldn't find special form
....
nfs: commencing msieve filtering
27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093
checking relations array at location 1
checking relations array at location 1
checking relations array at location 1
nfs: commencing msieve linear algebra
linear algebra completed 178084 of 179443 dimensions (99.2%, ETA 0h 0m)
nfs: commencing msieve sqrt
NFS elapsed time = 1844.8132 seconds.
Total factoring time = 1895.3412 seconds


***factors found***

P55 = 4009233200275881669007420627248030065788133608728404689
P46 = 6905885536470833185864058916647404865761283437

ans = 1[/code]

[QUOTE=kotenok2000;624508]I can't factor 27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093
It freezes on commencing Lanczos iteration (8 threads)
memory use: 71.9 MB
with no cpu usage.
yafu "factor(27687305570123882468203735526899284256078398738059989078472112075185421896509959250815385106168836093)" -p -threads 8

also it outputs
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.
line 225 - Failed to obtain a task from the jobs queue.
line 274 - Warning an error has occurred when trying to obtain a worker task.
line 275 - The worker thread has exited.[/QUOTE]

That error comes from inside the msieve library, and I haven't tracked down why it happens or how to fix it yet. Fortunately if you restart the job with the existing data set it should work.

from when did this msieve library error begin to appear and from what commit should i download yafu-x64.exe?

[QUOTE=bsquared;624511]That error comes from inside the msieve library, and I haven't tracked down why it happens or how to fix it yet. Fortunately if you restart the job with the existing data set it should work.[/QUOTE]

I've also been getting a similar error when I attempt to use 12 threads on YAFU 2.10, win 11, i7-12700k. It will either give the "workers failing to obtain tasks" messages or just silently hang at 0% cpu usage indefinitely. Retrying the job with 12 threads gives the same error, but restarting and only using 1 thread has successfully finished the job. For reference I was factoring C122 10090384354409393447889290770153099989080270065910033870159468230862477669938715326805661791618012360797542282091005502603

I'd attempt to see if 2.9 circumvents this problem but I'm not sure where to find older yafu binaries.

You can download them from github history.
[URL="https://github.com/bbuhrow/yafu/commits/master/bin/x64/Release"]https://github.com/bbuhrow/yafu/commits/master/bin/x64/Release[/URL]
Looks like yafu-x64 from commit aec7526 works.

[QUOTE=kotenok2000;624767]You can download them from github history.
[URL="https://github.com/bbuhrow/yafu/commits/master/bin/x64/Release"]https://github.com/bbuhrow/yafu/commits/master/bin/x64/Release[/URL]
Looks like yafu-x64 from commit aec7526 works.[/QUOTE]
Replacing my yafu-x64 executable in the directory with that one (after removing the cado related ini args) got me up and running! My only remaining yafu trouble is that I wish there was a way to estimate gnfs time ahead of actually running it.