![]() |
While doing ggnfs using aliqueit factoring a 110 digit number:
Found 6301083 relations, need at least 2868670 to proceed. => "d:/aliquot/ggnfs/msieve.exe" -s test.dat -l ggnfs.log -i test.ini -v -nf test.fb -t 1 -nc1 It still didn't seem to have enough however and is looking for more despite the number of relations being over twice the 'needed' amount. I just wanted to double-check that this is normal and doesn't indicate a problem. Also the line: filtering wants 1000000 more relations in the output - the number it seems to want here seems kind of random with 1 million showing up a lot. I would think this value should decrease, but it doesn't seem to. I guess the real question is whether you can tell if it close to finished. |
[quote=Greebley;176571]While doing ggnfs using aliqueit factoring a 110 digit number:
Found 6301083 relations, need at least 2868670 to proceed. => "d:/aliquot/ggnfs/msieve.exe" -s test.dat -l ggnfs.log -i test.ini -v -nf test.fb -t 1 -nc1 It still didn't seem to have enough however and is looking for more despite the number of relations being over twice the 'needed' amount. I just wanted to double-check that this is normal and doesn't indicate a problem. Also the line: filtering wants 1000000 more relations in the output - the number it seems to want here seems kind of random with 1 million showing up a lot. I would think this value should decrease, but it doesn't seem to. I guess the real question is whether you can tell if it close to finished.[/quote] You'll need about 7M relations, give or take a few hundred thousand. The problem is that the "x" in "need x to proceed" is only based on the values of lpbr and lpba, and as factMsieve.pl is designed for SNFS as well (which needs less relations for the same lpbr and lpba), the formula is adjusted for that. Hacking factMsieve.pl is something we all do. |
Filtering can proceed when the number of relations exceeds the number of ideals by a specific amount. If your current amount is less than the target, the filtering decrees you need 3x the difference in extra relations. This is somewhat accurate only if you have nearly enough relations already (i.e. the run is perhaps 2/3 finished). If you have fewer relations than ideals, then you are far from having enough relations so the filtering decrees you should check again after a million additional relations.
Also, don't be surprised if the target increases as more relations become available. This is because more relations allow more ideals to survive the singleton removal, which makes the target harder. |
Is there a way to get the elf files for a sequence? I currently have to go to the database and display the sequence in text and do a cut and paste. This seems inefficient.
If wget can send a sequence to the database, could this be reversed and another argument gets the existing sequence before it runs? |
[quote=Greebley;177029]Is there a way to get the elf files for a sequence? I currently have to go to the database and display the sequence in text and do a cut and paste. This seems inefficient.
If wget can send a sequence to the database, could this be reversed and another argument gets the existing sequence before it runs?[/quote] 100000-200000: get them at [URL="http://www.frontiernet.net/"]Frank's site.[/URL] There are also a few from the early 200000-300000 range. I suggest you have a little peek in the useful links thread. |
[QUOTE=Greebley;177029]If wget can send a sequence to the database, could this be reversed and another argument gets the existing sequence before it runs?[/QUOTE]
It's an interesting idea and would be quite useful if all the elves hung out at Syd's place. I'll try to squeeze it in, but it may be a while. |
I have a question about the ecm part of the run. For a given factor, if you rerun the ecm part a second time using aliqueit is there any benefit?
If it runs the exact same elliptic curves then the answer would be no, but if random elliptic curves happen to be run, then it is possible you might stumble across a factor. I ask because if I have to abort the ecm calculations 10 of 12 hours in and it is always the same curves, then rerunning 10 hours of repeats just to check the last 2 seems a waste. However, if the curves are random and I am checking new values that might get a result then the ecm makes more sense and I might as well let it run. If they are repeats, then the question becomes whether there is a way that aliqueit.exe could add a bit of randomness in its call to get the ecm program to check different curves. |
[QUOTE=Greebley;177650]I have a question about the ecm part of the run. For a given factor, if you rerun the ecm part a second time using aliqueit is there any benefit?[/quote]
Absolutely. They're random curves. |
It is not completely wasted since they're random curves, but it is not the best since you're running more ECM than is optimal. (assuming aliqueit runs approximately the optimal amount of ECM, which I think it tries to)
(I'm not saying mklasson's "Absolutely" response to "is there any benefit?" was incorrect, just incomplete.) |
[QUOTE=Mini-Geek;177662](assuming aliqueit runs approximately the optimal amount of ECM, which I think it tries to)[/QUOTE]
Tries and approximately being the key words. :smile: |
Ya, I think I understand the concept. The more curves run and fail, the greater the chances are that the factors are quite large and ecm is unlikely to work.
That is why I used the term "any benefit" - to clarify what I wanted to know. In this case I have a c120 so too few (and not finding one that I could) is worse than too many I am thinking. The number 232800 is being very annoying. Its around size 123 with no driver, and it is looking like I need to run the second c120 through ggnfs after doing a ggnfs run: c120 = c19 x c102 only 4 iterations ago (and a c110 in between). |
| All times are UTC. The time now is 21:52. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.