![]() |
|
|
#78 |
|
Mar 2006
Germany
55348 Posts |
If you're using WIN: "wget.exe" can be found in this ZIP.
To upload seq-indices manually, goto this link, copy all lines as they are in the text-inputbox and press "Report". It could take some time, until all is shown in the FactorDB. Last fiddled with by kar_bon on 2010-08-24 at 00:46 |
|
|
|
|
|
#79 |
|
A Sunny Moo
Aug 2007
USA (GMT-5)
3·2,083 Posts |
Note that unchecking "insert in background" should make it happen a little faster; it may seem to sit for a while after you hit "report" before it says it's done, but once it's finished everything should be in the database right away.
The "insert in background" option, IIRC, was created mainly in response to users submitting massive factor tables on a regular basis; adding comparatively few lines to the end of an Aliquot sequence as in this case is not going to create any significant adverse effects for the DB. Also, it helps decrease the load on the DB (and make it not take as long to insert) if you just submit lines that are new since you reserved the sequence. |
|
|
|
|
|
#80 | |
|
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
17·251 Posts |
Quote:
|
|
|
|
|
|
|
#81 |
|
Sep 2008
Kansas
3×1,129 Posts |
59688 is done; at 110 digits, 2^4 * 31 * p13 * c95
reserving 62916 |
|
|
|
|
|
#82 | |
|
Jul 2009
238 Posts |
Quote:
-> ___________________________________________________________ -> | This is the factMsieve.pl script for GGNFS. | -> | This program is copyright 2004, Chris Monico, and subject| -> | to the terms of the GNU General Public License version 2.| -> |__________________________________________________________| -> This is client 1 of 1 -> Using 1 threads -> Working with NAME=test... -> Error: Polynomial file test.poly does not exist! -> Found n=744659706015784927103669239476685054756540107788131238593246699679434 80719200960484110626315256759. -> Attempting to run polyselect... -> Selected polsel parameters for 98 digit level. Could not find default parameter file ../../ggnfs/bin/def-par.txt! WARNING: gnfs failed to find a factor. This really shouldn't happen. I'll just run ecm till the end of time or a factor turns up... Let's hope you don't run out of disk space before either of those. 683 . c103 = 3997035438010327174721655009815054699911204682563573236273110985 199334271083830754945121978097721796084 = 2^2 * 3^3 * 7 * 71 * 56743331810311435 341559738620661 * 13123298936782997974205520516723234799200518705749523365761454 12219 684 . c103 = 8012836300612252129606322484465133515767526612034735366393665499 570583369828953508536969589403711343116 = 2^2 * 3^2 * 7 * 43 * 757 * 1531 * 9798 62489 * 108641279887671439 * 599357850394716295454403496136708090367558039661119 0747736878789383 c86: running 195 ecm curves at B1=25e4... So as you see, pretty much after I start typing this, it found the factors. But the error kinda made me worried ![]() SAB |
|
|
|
|
|
|
#83 |
|
"Ed Hall"
Dec 2009
Adirondack Mtns
1110111110102 Posts |
Hi Sab,
You might want to review this thread on a newer script to use instead of factMsieve.pl. The newer one is factmsieve.py and you would need to run it via Python instead of Perl. If you are running Windows, I would also offer a look at AliWin (developed by me). There is also a thread about it here. Welcome to the forum and Aliquot Sequences. |
|
|
|
|
|
#84 | ||
|
Nov 2008
2·33·43 Posts |
Quote:
Quote:
Also, delete the msieve.exe that comes with GGNFS, and make sure that the msieve_cmd in aliqueit.ini is the full path to the more recent version of msieve which you have downloaded. factMsieve.py may still have a few bugs in it, so I would recommend staying with factMsieve.pl for the time being. Anyway, good luck!
|
||
|
|
|
|
|
#86 |
|
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
10000101010112 Posts |
57546 is done (110 digits, 2*3^2, stopped at c98 with full ECM).
|
|
|
|
|
|
#87 |
|
Jul 2009
19 Posts |
Hello again,
After a day or so of running, I have three more problems/ errors. First of all, I made sure msieve was in the right place (the error is not turning up again so Ill take that as a good sign.), and I changed the $GGNFS_BIN_PATH to the correct path. So Ill show some of my output and then the errors: -> Searching leading coefficients from 84317001 to 84318000. => nice -n 19 "C:/Users/Steven/Desktop/PrimeNumbers/Aliquot/ggnfs/pol51m0b.exe" -b test.polsel.Steven-PC.6692 -v -v -p 4 -n 1.4E+015 -a 84317 -A 84318 > test.p olsel.Steven-PC.6692.log 'nice' is not recognized as an internal or external command, operable program or batch file. -> Searching leading coefficients from 84318001 to 84319000. => nice -n 19 "C:/Users/Steven/Desktop/PrimeNumbers/Aliquot/ggnfs/pol51m0b.exe" -b test.polsel.Steven-PC.6692 -v -v -p 4 -n 1.4E+015 -a 84318 -A 84319 > test.p olsel.Steven-PC.6692.log 'nice' is not recognized as an internal or external command, operable program or batch file. -> Searching leading coefficients from 84319001 to 84320000. => nice -n 19 "C:/Users/Steven/Desktop/PrimeNumbers/Aliquot/ggnfs/pol51m0b.exe" -b test.polsel.Steven-PC.6692 -v -v -p 4 -n 1.4E+015 -a 84319 -A 84320 > test.p olsel.Steven-PC.6692.log 'nice' is not recognized as an internal or external command, operable program or batch file. Polynomial selection failed. WARNING: gnfs failed to find a factor. This really shouldn't happen. I'll just run ecm till the end of time or a factor turns up... Let's hope you don't run out of disk space before either of those. c102: running 0 auto-increasing ecm curves... 1. It cant recognize the "nice" command even though I took out the comment symbol. ($NICE="nice -n 19 ";) 2. ggnfs keeps spamming similar output to the screen(the above happened 1000's of times) 3. I also get the same old "end of time" error. If you guys have the patience to keep answering my questions, I definitely will have the patience to keep trying this :P Thanks again, SAB p.s. when the programs are running the ecm curves, is there any simple way to display what curve it is currently testing? c102: running 609 ecm curves at B1=1e6... took about 1 hr 15 minutes to complete. Its the exact opposite problem compared to the verbose problem stated above. And how do you save the program in the middle of an ecm curve? Otherwise I have to start at the beginning of the index. -p -e does not seem to do the trick. Last fiddled with by Sab on 2010-08-24 at 23:49 |
|
|
|
|
|
#88 | ||||
|
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
17·251 Posts |
Quote:
More info on why: ("nice" is a Unix utility to run a program at a specified priority; $NICE is an optional variable which will make the script try to use "nice" when it runs certain programs so they run at a lower priority) It's not necessary. Even less so when run through aliqueit, because the priority of aliqueit decides the default priority of the things it runs. If you want it to run at low priority, use -p when you run aliqueit, if not then don't. And the error isn't saying it can't tell what "$NICE" means, it's saying that the "nice" that's trying to run can't be found. (end of the "More info") Also, it looks like you haven't done this, either that or msieve didn't find a polynomial for some reason: Quote:
Quote:
Quote:
To understand this, here's a little relevant information regarding ECM, curves, and how that all works: Each ECM run is called a curve. Each curve has a small chance to find a factor. Each curve chooses a random number, called a sigma, so that it is different from other curves It is most efficient run a large number of curves (hundreds) at several levels (each larger 'level' takes longer for each curve and requires more curves, but finds larger factors) before switching to a factoring method like SIQS or GNFS. If you run 100 out of 400 curves at a certain level, you don't need to do anything to 'save' that status. You just need to run 300 more curves to finish that level (i.e. have a good chance that there are no factors of the size that level is good at finding). Where it gets a bit more complex is if there would've been more levels after the one you stopped at, because then you require a bit more knowledge than just looking at the outputs. So anyway, to manually finish ECM, first find out what you need to do. Let's say aliqueit last said it wanted to run 609 curves at B1=1e6 and you interrupt it. Say looking at aliqueit_ecm_temp.log shows that 162 curves finished. You need to run 447 more curves to complete (you should remember/know that since ECM is random, you're really not deterministically "completing" anything, you're just fairly sure that on average now is when you should stop to be the most efficient). You can do that with GMP-ECM, which is ecm.exe, the same program aliqueit uses. Run ecm -h to get help on using it, and be careful that you don't run it in a way that the factors will vanish from all view once they're found. Use -one so that it'll stop if it finds a factor. You can use -n or -nn to reduce the priority. You must specify the B1 on the command line, and you can specify the number to factor (can be found at the top of aliqueit_ecm_temp.log) on the command line or by pasting it and pressing enter once you run the command. Read the help for more info on all this. The command might look like "ecm -c 447 -one 1000000" and then you paste the c102, press enter, and it starts looking for factors of the c102, using 447 ECM curves with B1=1e6, stopping if it finds a factor. If you find a factor, give it to aliqueit using -f (see aliqueit's help). If you don't, you can run aliqueit with -e to have it skip ECM. For more info: http://mersennewiki.org/index.php/Elliptic_curve_method http://en.wikipedia.org/wiki/Lenstra..._factorization I know this is a lot of information, but I hope it doesn't confuse you too bad. If you don't mind losing some efficiency, you don't need to know much. It's if you really want to do just the right amount of ECM that you need to start knowing a lot more (or to a lesser extent, avoiding duplication or missed factors, as the above talks about).
Last fiddled with by Mini-Geek on 2010-08-25 at 00:52 |
||||
|
|
|
![]() |
| Thread Tools | |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Subproject #7: 100k-150k sequences to 110 digits | 10metreh | Aliquot Sequences | 185 | 2011-01-24 18:43 |
| Subproject #4: 10k-50k sequences to 110 digits | 10metreh | Aliquot Sequences | 345 | 2010-07-28 07:20 |
| Subproject #5: 800k-900k sequences to 100 digits | 10metreh | Aliquot Sequences | 431 | 2010-05-18 02:21 |
| Subproject #3: 700k-800k sequences to 100 digits | henryzz | Aliquot Sequences | 697 | 2010-02-04 04:36 |
| Subproject #1: 210k-250k sequences to 100 digits | henryzz | Aliquot Sequences | 204 | 2009-07-30 12:06 |