[QUOTE=3.14159;237011]Were those random or not?

Oh, wait, it's stupid to ask that question, probably pseudorandom and therefore nonrandom.[/QUOTE]

I could ask the same question of you, I suppose. Did you use radioactive decay or atmospheric noise to generate yours?

I'm thinking of starting factor work on a 110-digit number; Leave it be overnight.

59871850441883979044405428847542168288138150651887598225568902241762187682493909226207334528522020202725805381 is the number to factor.

Update: .. No way in hell that's going to happen.. That would take weeks..

74338891272149377427874674085271601642998185764655979027122653603490870033854228718287247388242120669311638350 = 2 * 3 * 5 * 5 * 17 * 19 * 43 * 101 * 311 * 739 * 116089 * 56917967 * 85348061 * 24947787413 * 167004293206339246027388107 * p39
38157159043738331401770964558106272101132422830636574102031515637789982659143857425996997108344070816764016398 = 2 * 3 * 383 * 2207 * 49782128129 * 51632606880677 * 156884557596929 * 35326563739232550038346583 * p39
11314500073059879067886420101455744756056583155142547166688513231714281478559695041703165299690029082907304664 = 2 * 2 * 2 * 7 * 13 * 743 * 14253409 * 38342281 * 87109567 * 232021873 * 350751703 * 908198324477 * 371162877118224182083 * p32
38883006611497575841712984979937342738910548225867207643379880594896105015715234112134584827624939020648574364 = 2 * 2 * 3 * 3 * 13 * 19 * 139 * 797 * 953 * 3257 * 15583 * 2740853 * 34977359 * 310700502904243953576307 * p53
57154156281492131910314562461340925913051944956802811736273712026632015939560259856292966072562836085732464260 = 2 * 2 * 3 * 5 * 23 * 29 * 31 * 37 * 7583 * 12253 * 88609 * 733511 * 18392476667797 * 22718716829477 * 38909979964631862673 * p38
11319605852137651873403299821012824711353456801354811440918206799022343059180006953094526111916258398453892206 = 2 * 3 * 3 * 7 * 19 * 31 * 113 * 1839427 * 79429547 * 84050827901 * 44899644930840362563 * 310863964758761491678397003 * p31
21253390829391485599579071715096746356539968858721165124074898220673020203691756740591620783581417537349600524 = 2 * 2 * 3 * 61 * 199 * 1831 * 4973 * 12985217471 * 103559428601 * 1652431643381920607578972385063 * p46
17656425106311690323287834186253129439586141910462304868361141029659008087286680063906706096470233598526787089 = 3 * 3 * 37 * 43 * 47 * 53 * 67 * 97 * 1217 * 1511 * 12799 * 55949 * 1558103 * 29636798459 * 61746720158803 * 27801348173060546509221263 * p27
10235945216789034618704567927879704249747724066834656445615415712014237345917819634728542736764868908944797893 = 7 * 29 * 31 * 37 * 136621 * 11917334171 * 184132753821836720843 * 31767599544330932051496130561 * p40
68302099261155078078235897584706041151104132298645035742120788756482833523311597129517261530492922001577292164 = 2 * 2 * 7 * 13 * 13 * 61 * 3691 * 24337 * 1418561 * 17319670189 * 522621860509518597887657005161133813 * p45

[QUOTE=3.14159;237018]I'm thinking of starting factor work on a 110-digit number[/QUOTE]

You've reached the the lower end of my stockpile of composites. For example here's the unfactored residual from a cyclotomic number.
[code]52074219475176599544589880036618463852389141452984899716122268110474982992898184859374665810756777666157468887[/code]

[QUOTE=wblipp;237083]You've reached the the lower end of my stockpile of composites. For example here's the unfactored residual from a cyclotomic number.
[code]52074219475176599544589880036618463852389141452984899716122268110474982992898184859374665810756777666157468887[/code][/QUOTE]

The number I used above was a p55 * p55. I take it that this might be a similar case, but I think it would be unrealistic; It would take weeks using a mere four-thread box for YAFU. Then, there's the GGNFS/Msieve application.

I can run Msieve easily, but I just can't seem to be able to set GGNFS up. If I could set it up, and give it a test number, say, a 100 or 105-digit number, to test its performance, maybe, just maybe, my range of numbers to factor would be extended to about 130 digits, or p65 * p65.

Here would be a nice example of a test number:

21773062350309841033157922516689393992032263697886427348664223252931714352536971180880778110859557388403. I set it up so that it's p52 * p52.

If it can handle that, then, I might test the c110 I posted earlier.. That means, I'll have to get to work getting the binaries.

Okay; I set them up to be in the factoring directory, where YAFU and GMP-ECM reside. Onwards to the rest of the guide.. If I could make head or tail out of it, that is.

This step confuses me; [QUOTE=Beginner's Guide][B]Obtain the latest MSIEVE binaries (v1.43 or newer) and overwrite the msieve that comes with ggnfs.[/B][/QUOTE]

Do they mean, download Msieve and replace the msieve already there? :huh:

[QUOTE=3.14159;237113]Do they mean, download Msieve and replace the msieve already there? :huh:[/QUOTE]

Yes, the version of msieve that comes with ggnfs may not be up to date.

[QUOTE=CRGreathouse;237118]Yes, the version of msieve that comes with ggnfs may not be up to date.[/QUOTE]

Okay; Got it.

.. Done. The latest version is 1.47.

.. Then there's Python and the Python script, which I already have.. Copy-pasted there..

I also got rid of the superfluous files.

The next steps are where I normally get lost.. It says, I should make a separate directory for the number I want to factor, then make some edits to the lines of the Python script..

How maddening..
 

[B]-> Could not find the program: msieve.
-> Did you set the paths properly in this script?
-> They are currently set to:
-> GGNFS_BIN_PATH = ../
-> MSIEVE_BIN_PATH = ../[/B]

[QUOTE=3.14159;237138][B]-> Could not find the program: msieve.[/B]
[B]-> Did you set the paths properly in this script?[/B]
[B]-> They are currently set to:[/B]
[B]-> GGNFS_BIN_PATH = ../[/B]
[B]-> MSIEVE_BIN_PATH = ../[/B][/QUOTE]
This assumes that you are running the factorization from a subdirectory of your main GGNFS directory; this is commonly done to avoid getting files mixed up (which is easy to do since the ggnfs binary suite is expansive and quite a few files are produced during the factorization).

What you'll want to do is create a subdirectory off the GGNFS directory for this particular factorization; place your .n file in there (formatted properly--if you need help with this see [URL]http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html[/URL]). Then open a command prompt to the subdirectory and run:

../factmsieve.py filename.n

Assuming you have Python installed correctly (which it looks like you do to have gotten as far as you did), this should do the trick. The script will begin factoring the number given in filename.n, placing all of its temp files in the subdirectory. When you're done and have the factors, you can delete the entire subdirectory and handily clean up after yourself. (The relations files produced during the factorization can be sizeable, so you'll definitely want to clean up afterwards.)

[QUOTE=Max]What you'll want to do is create a subdirectory off the GGNFS directory for this particular factorization; place your .n file in there (formatted properly--if you need help with this see [url]http://gilchrist.ca/jeff/factoring/n...ers_guide.html[/url]). Then open a command prompt to the subdirectory and run:

../factmsieve.py filename.n[/QUOTE]

Okay; Here is my GGNFS directory;

...\Downloads\Factoring\ggnfs-svn360-win64-core2

So, this would be the path for the subdirectory:

...\Downloads\Factoring\ggnfs-svn360-win64-core2\tobefactored\example.n?

[QUOTE=3.14159;237140]Okay; Here is my GGNFS directory;

...\Downloads\Factoring\ggnfs-svn360-win64-core2

So, this would be the path for the subdirectory:

...\Downloads\Factoring\ggnfs-svn360-win64-core2\tobefactored\example.n?[/QUOTE]
Correct.

[QUOTE=mdettweiler;237141]Correct.[/QUOTE]

Well, I tried that and got no luck;

I also noted something interesting:

The pack has one of its files missing. Luckily, I forgot I had a spare copy, which I got around July-August, apparently. I will see how that works out.

.. The only problem is, that annoying problem of the correct path.. There must have someone other than I who ran away from this because it's impossible to set up..

[QUOTE=3.14159;237147]Well, I tried that and got no luck;

I also noted something interesting:

The pack has one of its files missing. Luckily, I forgot I had a spare copy, which I got around July-August, apparently. I will see how that works out.

.. The only problem is, that annoying problem of the correct path.. There must have someone other than I who ran away from this because it's impossible to set up..[/QUOTE]
Hmm...did your copy of GGNFS come with an msieve.exe binary? Mine did (albeit a very old copy) but I got it a while back. If you don't have msieve.exe in your GGNFS directory, grab the latest version from [URL]http://sourceforge.net/projects/msieve/[/URL].

If that doesn't work, try replacing the "../"'s with absolute paths. That is, with "...\Downloads\Factoring\ggnfs-svn360-win64-core2" (replacing with whatever full path is in its place).

Y'know, I've always had the idea that one day, I might be able to have a somewhat impressive semiprime integer split into its factors, like this;

[code]34202459310305167332073477050434588029922904302593504279353572001153771881481122935589269582256218330011913588589287285938611761601312404711541389297229774861463835999831 =

4474901351001318687510657405661030821171754716612970370265520870318598719901177600069 * 7643176156866991540331200941525581679369244062690306474322557206918623812221160197099[/code]

[QUOTE=CRGreathouse;237010]Pfft, here's 100.

Oops, the forum won't let me post that many characters. OK, here's the amount I can fit into a post.

[code]3828341080244400637832496477959805704164073468183074462634180957833651864984723682138669035433026500 = 2 * 2 * 3 * 5 * 5 * 5 * 7 * 19 * 19 * 23 * 37 * 53 * 241 * 1181 * 5649913 * 36081377 * 8581181173 * 47840420649221 * 56402348128571 * p32
1588660322983396302885796245830814329302488843364165698215578492464397730424401789229489704601075756 = 2 * 2 * 3 * 7 * 13 * 23 * 47 * 61 * 181 * 15031 * 526483 * 927323 * 1148527 * 406979061818023 * 81538217474440208479553 * p30
1021031048497837374483531447808891337935989532331588576367878602517111431033593224173329292881512173 = 31 * 367 * 30809 * 5668727 * 908392703 * 1028314699 * 2197843586849586383840467 * p42
7086422853097868451711345316509410180470376785600011857778722004533443743419826800885302936650498470 = 2 * 5 * 13 * 19 * 29 * 431 * 587 * 691 * 2767 * 942187 * 1893539 * 2597779 * 15624896897 * 1610494874908351 * 3845935534903586029 * p21
4318456126006444342857842557107114096633481415982568386769884274414806491142401044261345969736720694 = 2 * 3 * 7 * 11 * 13 * 23 * 31159 * 302053 * 30936197387 * 4176718791229 * 847849456387121 * 2254092997188947242409 * p26
1109587849660304353836201770893761411871650688020685001076825645933095103648972795052962839552595690 = 2 * 3 * 3 * 5 * 7 * 23 * 31 * 67 * 163 * 85632998041 * 17249535181483504313 * 394021370780626750477817951 * p33
2979941477970790621634249796909439789746784691205449811130412558873271515382744651517007594645175894 = 2 * 3 * 11 * 13 * 19 * 97 * 1637 * 706109 * 60265063 * 59542983281711851 * 6457175558840031600628637783 * p32
6420726987540740841706278258860741277295366130264261913963063511707914602848605467111390751821088121 = 3 * 7 * 97 * 1481121042485345479125151 * 176615229066307992468364472796139 * p41
9816138939953536743143344071912358383004405759221258712071041553368290365584815105024598168207976103 = 839 * 10399 * 4264780100791321147 * 8561427410274222444303852083 * p47
2268168812216914591854154823153328155076179646049376828112834528320073183563365268538263313054628020 = 2 * 2 * 3 * 3 * 5 * 7 * 7 * 23 * 31 * 31 * 37 * 61 * 73 * 479 * 523 * 1486553277901 * 2312246873086067716693912462289027 * p35
2175187002194884841675973456689521692815926892066030053856510088603896308976058660302016139102867286 = 2 * 17 * 43 * 199 * 317 * 17207 * 595611953 * 374487601672675901611 * 120397871923043244929719 * p35
1964666465908214969730131549122817558003317961763724416749317778247127635667033822930173507293655037 = 1409 * 2621779 * 572550962994499639130106764801815763499954743 * p45
2109835988366518432588338355806050669474506758795640108970282822027494388216935165502614463059840500 = 2 * 2 * 3 * 3 * 5 * 5 * 5 * 13 * 17 * 53 * 53 * 89 * 241 * 279464069 * 13390332799 * 13566564771765494922641095631 * p39
4170436258982883679101363076894140796229193134975892831177906516068402234097418053129515314672448236 = 2 * 2 * 17 * 2069 * 131381 * 147541 * 392669 * 1385569 * 8654839 * 1817213413 * 641105533842841 * 22777900103786411 * p26
1112745709173761896559835695316280609014296134651327666778801370828688600198148161143564180857076834 = 2 * 3 * 7 * 11 * 31 * 47 * 317 * 19381 * 182617 * 304849 * 589163046401 * 490279242759107592236447059 * p38
6754467728048555661382638518307179841909700849996023430663298769830785246937785624396484840143801820 = 2 * 2 * 5 * 13 * 19 * 23 * 29 * 83 * 97 * 2029 * 102139 * 175919 * 28920977 * 37222903 * 3325507556831 * 113026544095967 * p35
9290303292654677796208450313997479786862212010805900056412444714830815535310109739094853648011955880 = 2 * 2 * 2 * 3 * 5 * 19 * 19 * 53 * 139 * 149 * 2633 * 254557 * 7518315653802366207934294760412271 * p47
1519045907326352179272495192012691255110343871460740344723603485053123113376600850827082587042722632 = 2 * 2 * 2 * 3 * 3 * 3 * 7 * 7 * 7 * 7 * 11 * 13 * 19 * 23 * 73 * 953 * 8039 * 191531 * 650543 * 966923 * 2910837913 * 4712082339471169543 * p35
2297494279297747651318689357388091486187167887028748530651383542166405596399953892245633133215771067 = 3 * 19 * 1129 * 4909 * 45281 * 95483 * 350573551 * 185546423887211 * 5000505715976357 * p43
6916716710106028694497858360968629919200917839743569117166581989808297983518264029006195056926115135 = 3 * 5 * 7 * 313 * 599 * 701 * 887 * 117331 * 4657853 * 8510059 * 3519961031 * 34327729151 * 346541139438472730910749 * p25
4020646510893532589104720126916970485917983107805030705775412066914614392060823406100284080206300400 = 2 * 2 * 2 * 2 * 3 * 3 * 5 * 5 * 7 * 7 * 7 * 13 * 31 * 31 * 43 * 67 * 349 * 33623 * 102679 * 142159 * 229717 * 10307723 * 338788421 * 1427600611 * p39
7172656039606291939374148166929125456455438300989478240428912337825056979098115354643207581855835285 = 3 * 3 * 5 * 7 * 13 * 19 * 37 * 61 * 487 * 1121941560287 * 121409626878654282391474088573 * p48
2528919604826729658531053105058688132708635900874626524727189778747923659829992520183389956689288493 = 7 * 19 * 37 * 127 * 887 * 2347 * 149551999 * 140397312799 * 46097360176928611953517733 * p43
4780580308922684791934717889134818971136050278964890263719923034086360164542392367179511433499581230 = 2 * 3 * 5 * 11 * 47 * 107 * 199 * 3559 * 101399 * 226307 * 1130190559 * 12732542650017211591 * 130385357953530112759 * p29
1771581299718052268780183255753188184264364543991851960093639623289282075054030826702670725925580126 = 2 * 3 * 7 * 23 * 73 * 1621 * 440681 * 57252901 * 9424402487 * 555590203710791497 * 1664351435128005575192027 * p26
1826607301881605308867617623466131387321007525492908119055581832481636954149723135560049573051779689 = 3 * 7 * 8731 * 11971 * 86423 * 133697 * 6175693 * 3399940349409841 * 228101887805109423382486397 * p32
5012088009277640314402761559890041839759396057018545897258241994190447331558998944288170990344028751 = 2917 * 1757549 * 85744849549 * 77390355798296212981 * 117857840533006506831097561 * p34
1118682071008816168222725102230550120702126996309533995481998016819660387118847018742147190609638748 = 2 * 2 * 3 * 7 * 7 * 7 * 11 * 31 * 31 * 15107 * 66041 * 3629831 * 32303143 * 3644664791 * 3669739756759 * 9842283515159 * p34
3409719665791495912088557548714548870555928299445478456550560379913289306779291543643147189360470373 = 13 * 63079 * 1897177 * 6700089011507840929048948172217533113246337 * p45
1495013387078444830971209867702573522460009718985740283372631172961535442849970157536302235575256418 = 2 * 3 * 7 * 7 * 7 * 23 * 43 * 683 * 1069 * 11941 * 79943 * 174767 * 3055399 * 15229428191 * 97167102001 * 342494678174970979223 * p25
4525811937133892039004695583122389645196403182725701117694456147561445885523093800196418939098804213 = 3 * 7 * 127 * 181 * 971 * 1249 * 2417 * 938338889863 * 1435055134111 * 14576177493396886245107 * p39
2073311625512958451771092516352979522018668970964146344058841979417884026793493734398961719458991714 = 2 * 7 * 83 * 683 * 2927 * 2853337 * 14091887522033 * 229463148114318047593 * 119858213886351109516757 * p27
2898380564764331740650976346727898110985597681040329046593860520663948977367124731596264106185936093 = 3 * 3 * 101 * 151 * 271 * 1373 * 2153 * 17239 * 81239 * 2773871 * 7857481 * 899962939 * 82370557151 * 1455761853057791 * p28
3198477157946413712356473944979032360351567621787560078910437352396253167806937403734139451063110790 = 2 * 5 * 31 * 1543 * 31643 * 16930549 * 4315089697 * 147331735717257383607543819531715979 * p38
3122316024826623570999390780435061018523720250135414481535910292606995414401907413802207852764507150 = 2 * 5 * 5 * 13 * 53 * 9941 * 1095839 * 1436933 * 3566369 * 116278069 * 704550047 * 3739896647 * p46
1150279127692742245826975952975244459786635097720009368565532437170228458297750980752159689159559618 = 2 * 3 * 7 * 43 * 211 * 74843 * 487703 * 179282303 * 5191468757 * 279705792443006937347 * p45
3476994682280465721380107970080979643964773181753875578457560808630413498598886246958613562097879220 = 2 * 2 * 3 * 5 * 13 * 191 * 5912088495769122635780489 * 7782116779738216343902940458011407 * p36
2396930940518056525873755201487754594494952937746349126647824329949425055589025208870046787995076360 = 2 * 2 * 2 * 3 * 3 * 3 * 5 * 17 * 1361 * 13049 * 117243743 * 3537179857 * 13631427749 * 24865862748311267 * 83386179669921800083 * p24
5059444662280282391945087488109772319758228923707259715338382813207657103741168542070840844904146220 = 2 * 2 * 3 * 3 * 5 * 7 * 23 * 29 * 79 * 101 * 113 * 743 * 4831 * 2962207 * 4864957 * 15387939349 * 30166451450413001 * 22509974642730605057 * p23
9047865069205221785796363229531231728097227782231483365308238450563871586695628928251384364335276289 = 3 * 7 * 11 * 13 * 37 * 41 * 1327 * 1361 * 4243 * 29153 * 47513 * 9410983 * 55253941 * 219090281 * 1296987047 * 8269682713 * 84184045307 * p22
4818738698309238680979976982780739771434590565295500757251227197031479934194199257557409828463541162 = 2 * 31 * 79 * 379 * 25868233 * 64475011693 * 10929957278893 * 26357427070885165852945211371 * p34
7569920572151463447485708659596986502379885621035578545383014239308628711137659305904538890841093447 = 3 * 7 * 13 * 37 * 47 * 53 * 149 * 401 * 3457 * 34673 * 2494512199 * 13965069563 * 32420504751992087 * p44
7384425977124614373037190268769494322670515018022021984540726867123494391479847118318115045923964027 = 11 * 103 * 241 * 719 * 148709668309 * 51020820806647045557427500151889591 * p46
1460986172293537551768238256080060645982228305051951190204471703642679618463315789617586532311138454 = 2 * 3 * 31 * 47 * 673 * 1051 * 29478523 * 2049939233 * 120265998807826733 * 292426016421719911 * p39[/code][/QUOTE]

Could have posted those into a document.

A suitable number to leave YAFU working overnight..

54226171049950775045015304584853623265770119570639252888707467753514344661290463063582064327739908372829 (104 digits.)

That will set me a new record.

[QUOTE=3.14159;237741]That will set me a new record.[/QUOTE]

For my record of a SIQS-run with yafu see [url=http://www.mersenneforum.org/showpost.php?p=231694&postcount=724]here[/url].

[QUOTE=kar_bon;237749]For my record of a SIQS-run with yafu see [url=http://www.mersenneforum.org/showpost.php?p=231694&postcount=724]here[/url].[/QUOTE]

... I almost finished it, but it crashed instead of giving me factors.



[CODE]11/18/10 22:02:26 v1.20 , starting SIQS on c104: 54226171049950775045015304584853623265770119570639252888707467753514344661290463063582064327739908372829
11/18/10 22:02:26 v1.20 , random seeds: 2937123117, 3499815544
11/18/10 22:02:26 v1.20 , ==== sieve params ====
11/18/10 22:02:26 v1.20 , n = 106 digits, 350 bits
11/18/10 22:02:26 v1.20 , factor base: 140000 primes (max prime = 3952219)
11/18/10 22:02:26 v1.20 , single large prime cutoff: 592832850 (150 * pmax)
11/18/10 22:02:26 v1.20 , double large prime range from 45 to 53 bits
11/18/10 22:02:26 v1.20 , double large prime cutoff: 6184122292945686
11/18/10 22:02:26 v1.20 , allocating 10 large prime slices of factor base
11/18/10 22:02:26 v1.20 , buckets hold 2048 elements
11/18/10 22:02:26 v1.20 , sieve interval: 46 blocks of size 32768
11/18/10 22:02:26 v1.20 , polynomial A has ~ 14 factors
11/18/10 22:02:26 v1.20 , using multiplier of 29
11/18/10 22:02:26 v1.20 , using small prime variation correction of 22 bits
11/18/10 22:02:26 v1.20 , using SSE2 for trial division and x128 sieve scanning
11/18/10 22:02:26 v1.20 , trial factoring cutoff at 96 bits
11/18/10 22:02:26 v1.20 , ==== sieving started ( 4 threads) ====
11/19/10 04:29:16 v1.20 , trial division touched 1037885351 sieve locations out of 1691911094009856
11/19/10 04:29:16 v1.20 , 140700 relations found: 33259 full + 107441 from 2117572 partial, using 561228576 polys (1471 A polys)
11/19/10 04:29:16 v1.20 , on average, sieving found 0.00 rels/poly and 92.67 rels/sec
11/19/10 04:29:16 v1.20 , trial division touched 1037885351 sieve locations out of 1691911094009856
11/19/10 04:29:16 v1.20 , ==== post processing stage (msieve-1.38) ====[/CODE]
Then, an error message, "yafu has stopped working", or something to that effect.

I guess it doesn't work for anything larger than 100 digits..

[QUOTE=3.14159;237767]I guess it doesn't work for anything larger than 100 digits..[/QUOTE]

Definitely not. Don't guess, try again or read the manual.

Start again yafu, the found relations are stored so it will continue the test.

[QUOTE=kar_bon;237770]Definitely not. Don't guess, try again or read the manual.

Start again yafu, the found relations are stored so it will continue the test.[/QUOTE]

I guess I'll try once again..

.. No luck. It doesn't work for anything > 100 digits.

[QUOTE=3.14159;237847]I guess I'll try once again..

.. No luck. It doesn't work for anything > 100 digits.[/QUOTE]

[url]http://en.wikipedia.org/wiki/Hasty_generalization[/url]

[QUOTE=axn;237852][url]http://en.wikipedia.org/wiki/Hasty_generalization[/url][/QUOTE]

In that case, I respond to you with:

"Insanity: Trying the same thing over and over and expecting a different result."

A nice addition to YAFU would be an addition of NFS to it. (IMO.)

[QUOTE=3.14159;237855]In that case, I respond to you with:

"Insanity: Trying the same thing over and over and expecting a different result."[/QUOTE]

I've done it more than once without any probs.

[QUOTE=kar_bon;237858]I've done it more than once without any probs.[/QUOTE]

.. It must be the bastard computer, then..

Oh, not really..

[QUOTE= YAFU documentation]post-
processing courtesy of Jason Papadopoulos's msieve block Lanczos implementation.
[B]Useful for inputs < 105 digits.[/B] [/QUOTE]

100-105 is the best I can hope to do, in that case.

[QUOTE=3.14159;237860].. It must be the bastard computer, then..

Oh, not really..



100-105 is the best I can hope to do, in that case.[/QUOTE]
Note that useful != possible. While YAFU becomes not particularly useful over 105 digits (because the time it takes to factor a number with QS at that size grows quite a bit more quickly than that for GNFS), it can still be used if you really want to. As an example, just for grins the author of YAFU set a QS record a year or so back by using it to factor a 117 digit (size IIRC) number.

BTW, I'm assuming that you never were able to get GGNFS working? If you'd like, I can zip up my working copy of it and send it to you; I have a 32-bit Windows system so it should work for you as-is.

[QUOTE=mdettweiler;237874]Note that useful != possible. While YAFU becomes not particularly useful over 105 digits (because the time it takes to factor a number with QS at that size grows quite a bit more quickly than that for GNFS), it can still be used if you really want to. As an example, just for grins the author of YAFU set a QS record a year or so back by using it to factor a 117 digit (size IIRC) number.

BTW, I'm assuming that you never were able to get GGNFS working? If you'd like, I can zip up my working copy of it and send it to you; I have a 32-bit Windows system so it should work for you as-is.[/QUOTE]

The former; The thing crashes when I try a number that size!

The latter; It would be dearly appreciated.

I just made a nice text file of composites (What YAFU would class as RSA, ranging from 80-digit numbers to 160-digit numbers.)

Maybe I can zip up the composites and send them to you, in case you're interested in doing a bit of work. (Be warned; It's 8400, 8600, or 8800 composites, and surprisingly, it fit into less than 1 MB.)

About GGNFS; Let's say an n-digit number takes a certain amount of time, x. How many digits would need to be added to double the amount of time it takes to factor?

I'm guessing.. about 3-5.

[QUOTE=3.14159;237878]The former; The thing crashes when I try a number that size!

The latter; It would be dearly appreciated.[/quote]
Cool, will do. I'll put the package together and send it to you (via PM as a sendspace link) as soon as I can get the chance.

[quote]I just made a nice text file of composites (What YAFU would class as RSA, ranging from 80-digit numbers to 160-digit numbers.)

Maybe I can zip up the composites and send them to you, in case you're interested in doing a bit of work. (Be warned; It's 8400, 8600, or 8800 composites, and surprisingly, it fit into less than 1 MB.)[/quote]
No thanks--my CPUs are mostly booked to the end of the year. Also, while factoring random numbers can have an appeal when you're learning how to do factoring, it's sufficiently "old hat" to me by now that if I'm going to factor a number, I'd prefer it to be one that's going to be useful somewhere.

[quote]About GGNFS; Let's say an n-digit number takes a certain amount of time, x. How many digits would need to be added to double the amount of time it takes to factor?

I'm guessing.. about 3-5.[/QUOTE]
Just about right on. :smile: The rule of thumb is that factoring time doubles every 4 digits. (In reality it's a little more complex than that, but it works pretty well for an approximation.)

[QUOTE=Max]No thanks--my CPUs are mostly booked to the end of the year. Also, while factoring random numbers can have an appeal when you're learning how to do factoring, it's sufficiently "old hat" to me by now that if I'm going to factor a number, I'd prefer it to be one that's going to be useful somewhere.
[/QUOTE]

What are you actively working on? I don't remember all of the active projects..

[QUOTE=Max]Cool, will do. I'll put the package together and send it to you (via PM as a sendspace link) as soon as I can get the chance.
[/QUOTE]

Alright, seems fair enough.

Woohoo. A prime-numbered post. (1499)

[QUOTE=mdettweiler;237874]Note that useful != possible. While YAFU becomes not particularly useful over 105 digits (because the time it takes to factor a number with QS at that size grows quite a bit more quickly than that for GNFS), it can still be used if you really want to. As an example, just for grins the author of YAFU set a QS record a year or so back by using it to factor a 117 digit (size IIRC) number.
[/QUOTE]

It was a [URL="http://www.mersenneforum.org/showpost.php?p=161872&postcount=681"]C130[/URL], back in feburary '09. That was when I had access to a university opteron cluster.

[QUOTE=3.14159;237878]The former; The thing crashes when I try a number that size!
[/QUOTE]

That would be news to me... but I haven't tested number that big in quite a while, so its possible something broke. I'll have a look.

[QUOTE=bsquared]That would be news to me... but I haven't tested number that big in quite a while, so its possible something broke. I'll have a look.
[/QUOTE]

It's probably just me.. The number I intended to split was 54226171049950775045015304584853623265770119570639252888707467753514344661290463063582064327739908372829. (104 digits)

I already collected all the relations (140700 relations); It's the post-processing which fails.

Also; Wasn't the record for QS a 135-digit split, into a p66 and p69? I think it was for a cofactor of 2[sup]803[/sup] - 2[sup]402[/sup] + 1.

[QUOTE=3.14159;237881]What are you actively working on? I don't remember all of the active projects..[/QUOTE]
Mostly [URL="http://www.mersenneforum.org/forumdisplay.php?f=82"]No Prime Left Behind[/URL] (searching for general primes of the form k*2^n-1) and [URL="http://www.mersenneforum.org/forumdisplay.php?f=81"]Conjectures 'R Us[/URL] (proving Sierpinski/Riesel conjectures for bases <=1030). I have two machines, a quad and a dualcore; the quad is not as readily accessible, so on it I do strictly primality-testing work via PRPnet (currently for CRUS). The dualcore is my personal machine, so I do "special" jobs on it--currently one core is doing sieving for the [URL="http://www.mersenneforum.org/forumdisplay.php?f=65"]Twin Prime Search[/URL] and the other is running BOINC for [URL="http://www.primegrid.com/"]PrimeGrid[/URL] attempting to collect a full set of score badges. :smile:

[QUOTE=mdettweiler;237891]Mostly [URL="http://www.mersenneforum.org/forumdisplay.php?f=82"]No Prime Left Behind[/URL] (searching for general primes of the form k*2^n-1) and [URL="http://www.mersenneforum.org/forumdisplay.php?f=81"]Conjectures 'R Us[/URL] (proving Sierpinski/Riesel conjectures for bases <=1030). I have two machines, a quad and a dualcore; the quad is not as readily accessible, so on it I do strictly primality-testing work via PRPnet (currently for CRUS). The dualcore is my personal machine, so I do "special" jobs on it--currently one core is doing sieving for the [URL="http://www.mersenneforum.org/forumdisplay.php?f=65"]Twin Prime Search[/URL] and the other is running BOINC for [URL="http://www.primegrid.com/"]PrimeGrid[/URL] attempting to collect a full set of score badges. :smile:[/QUOTE]

Ah. Okay. Loaded with work..

[QUOTE=bsquared;237888] I'll have a look.[/QUOTE]

Worked fine, at least on a linux system. I'm running it on a windows 64 bit box too, just to check.

[CODE]==== sieving in progress (16 threads): 140064 relations needed ====
==== Press ctrl-c to abort and save state ====
141839 rels found: 33087 full + 108752 from 2125998 partial, (475.46 rels/sec)

trial division touched 1042298291 sieve locations out of 433495233003520
QS elapsed time = 4541.0364 seconds.

==== post processing stage (msieve-1.38) ====
begin with 2159085 relations
reduce to 379304 relations in 11 passes
attempting to read 379304 relations
failed to read relation 159902
failed to read relation 192757
recovered 379302 relations
recovered 356864 polynomials
attempting to build 141837 cycles
found 141837 cycles in 7 passes
distribution of cycle lengths:
length 1 : 33087
length 2 : 23115
length 3 : 23382
length 4 : 19500
length 5 : 15071
length 6 : 10531
length 7 : 6991
length 9+: 10160
largest cycle: 20 relations
matrix is 140000 x 141837 (46.5 MB) with weight 11067761 (78.03/col)
sparse part has weight 11067761 (78.03/col)
filtering completed in 3 passes
matrix is 134331 x 134395 (43.7 MB) with weight 10377051 (77.21/col)
sparse part has weight 10377051 (77.21/col)
saving the first 48 matrix rows for later
matrix is 134283 x 134395 (38.0 MB) with weight 9181311 (68.32/col)
sparse part has weight 8606295 (64.04/col)
matrix includes 64 packed rows
using block size 53758 for processor cache size 8192 kB
commencing Lanczos iteration
memory use: 29.1 MB
lanczos halted after 2125 iterations (dim = 134279)
recovered 16 nontrivial dependencies
Lanczos elapsed time = 107.1400 seconds.
Sqrt elapsed time = 2.0400 seconds.
SIQS elapsed time = 4650.2196 seconds.


***factors found***

PRP52 = 9469803592767274090918886597728739135915666061785411
PRP52 = 5726219189104085425290749098395506427807046278383839

ans = 1
[/CODE]

[QUOTE=bsquared;237897]Worked fine, at least on a linux system. I'm running it on a windows 64 bit box too, just to check.

[CODE]==== sieving in progress (16 threads): 140064 relations needed ====
==== Press ctrl-c to abort and save state ====
141839 rels found: 33087 full + 108752 from 2125998 partial, (475.46 rels/sec)

trial division touched 1042298291 sieve locations out of 433495233003520
QS elapsed time = 4541.0364 seconds.

==== post processing stage (msieve-1.38) ====
begin with 2159085 relations
reduce to 379304 relations in 11 passes
attempting to read 379304 relations
failed to read relation 159902
failed to read relation 192757
recovered 379302 relations
recovered 356864 polynomials
attempting to build 141837 cycles
found 141837 cycles in 7 passes
distribution of cycle lengths:
length 1 : 33087
length 2 : 23115
length 3 : 23382
length 4 : 19500
length 5 : 15071
length 6 : 10531
length 7 : 6991
length 9+: 10160
largest cycle: 20 relations
matrix is 140000 x 141837 (46.5 MB) with weight 11067761 (78.03/col)
sparse part has weight 11067761 (78.03/col)
filtering completed in 3 passes
matrix is 134331 x 134395 (43.7 MB) with weight 10377051 (77.21/col)
sparse part has weight 10377051 (77.21/col)
saving the first 48 matrix rows for later
matrix is 134283 x 134395 (38.0 MB) with weight 9181311 (68.32/col)
sparse part has weight 8606295 (64.04/col)
matrix includes 64 packed rows
using block size 53758 for processor cache size 8192 kB
commencing Lanczos iteration
memory use: 29.1 MB
lanczos halted after 2125 iterations (dim = 134279)
recovered 16 nontrivial dependencies
Lanczos elapsed time = 107.1400 seconds.
Sqrt elapsed time = 2.0400 seconds.
SIQS elapsed time = 4650.2196 seconds.


***factors found***

PRP52 = 9469803592767274090918886597728739135915666061785411
PRP52 = 5726219189104085425290749098395506427807046278383839

ans = 1
[/CODE][/QUOTE]

That's what I wanted to find..

Well, nice split..

I'll try another 104-digit number;

A slightly larger one; 56697489666723510791004886538373132330293426696343775288632713593821301055783186424906728020724813008339.

I think my computer's too weak to handle a c104. :no:

[QUOTE=3.14159;237898]That's what I wanted to find..

Well, nice split..

I'll try another 104-digit number;

A slightly larger one; 56697489666723510791004886538373132330293426696343775288632713593821301055783186424906728020724813008339.

I think the amount of threads I'm using is insufficient.[/QUOTE]

The general rule is to not use more threads than you have cores. Unless you have hyperthreads, which may give you a slight boost. The computer I ran this on is a dual hyperthreaded quad core, so 8 real cores and 8 hyperthreads.

Also, I just transferred the relations from the linux run to a windows machine, and resolved. everything worked fine there too, but I did notice that it took over 1 GB of ram... so maybe memory allocation is the problem you're seeing. Before you spend a bunch more time with a new number, see if you can free up some memory and retry the previous one, if you still have the relations.

[QUOTE=3.14159;237898]

I think my computer's too weak to handle a c104. :no:[/QUOTE]

Simply depends on how long you're willing to wait ;)

[QUOTE=bsquared;237901]Simply depends on how long you're willing to wait ;)[/QUOTE]

The relations only take 5 hours, so I can leave it running overnight. It crashes when it comes to the post-processing of the number.

[QUOTE=bsquared]so maybe memory allocation is the problem you're seeing. Before you spend a bunch more time with a new number, see if you can free up some memory and retry the previous one, if you still have the relations.[/QUOTE]

In the case of the number I showed you, yes, the relations are still there. The memory taken by the siqs.dat file is 168 MB. Should I get rid of that? Now that you've already done what I intended to do; I think I'll get rid of the stored relations.

I'll try factoring the number 56697489666723510791004886538373132330293426696343775288632713593821301055783186424906728020724813008339.

[QUOTE=3.14159;237903]The relations only take 5 hours, so I can leave it running overnight. It crashes when it comes to the post-processing of the number.



In the case of the number I showed you, yes, the relations are still there. The memory taken by the siqs.dat file is 168 MB. Should I get rid of that? Now that you've already done what I intended to do; I think I'll get rid of the stored relations.

I'll try factoring the number 56697489666723510791004886538373132330293426696343775288632713593821301055783186424906728020724813008339.[/QUOTE]

I meant free up RAM - if you are running a bunch of other stuff yafu could be unable to allocate the memory it needs to run the post-processing. I noticed it using over a gig of RAM for the C104, and more may be allocated (but not used).

[QUOTE=bsquared;237907]I meant free up RAM - if you are running a bunch of other stuff yafu could be unable to allocate the memory it needs to run the post-processing. I noticed it using over a gig of RAM for the C104, and more may be allocated (but not used).[/QUOTE]

Ah, okay. I don't have enough RAM to complete it.

I tried the number I posted, but failed yet again. My computer is indeed too weak to handle a 104-digit number. (Unless said 104-digit number is prime.)

Based on reading the beginner's guide; Indeed, 100-102 digits is as far as I can go. It would take 2-4 hours to factor a 100-digit RSA-type number, and a 155-digit number would take me ≈3.7 years to factor. (Unless I knew the factors beforehand.)

[CODE]c=[0];for(i=1,#mersenne,concat(c,(i/(i/log(mersenne[i])))))[/CODE]

I'm trying to get this working to try something based on a comment about [url]http://oeis.org/A000043[/url]. I can calculate the terms but I can't remember how to get them into the vector apparently, But I see that the items increase and I'd like to do something like findrec on them. Can anyone help ?

[QUOTE=science_man_88;237945][CODE]c=[0];for(i=1,#mersenne,concat(c,(i/(i/log(mersenne[i])))))[/CODE]

I'm trying to get this working to try something based on a comment about [url]http://oeis.org/A000043[/url]. I can calculate the terms but I can't remember how to get them into the vector apparently, But I see that the items increase and I'd like to do something like findrec on them. Can anyone help ?[/QUOTE]

Which comment?

In the meantime, I'll have to try setting up the bastard software..

[QUOTE=3.14159;237954]Which comment?

In the meantime, I'll have to try setting up the bastard software..[/QUOTE]

[QUOTE=http://oeis.org/A000043]It is believed (but unproved) that this sequence is infinite. The data suggests that the number of terms up to exponent N is roughly K log N for some constant K. [/QUOTE]I couldn't see regularity in i/log(mersenne[i]) so I went to i/(i/(mersenne[i])) which looks to be always increasing I'm just trying to find a pattern but I can't get it into a vector and I don't have excel to work with my beta of 2010 expired.

[QUOTE=science_man_88;237956]I couldn't see regularity in i/log(mersenne[i]) so I went to i/(i/(mersenne[i])) which looks to be always increasing I'm just trying to find a pattern but I can't get it into a vector and I don't have excel to work with my beta of 2010 expired.[/QUOTE]

Pattern? For what?

Sorry for what might be an FAQ, but can you use more than one thread while using msieve? If so, what's the proper command for it?

[QUOTE=3.14159;237960]Sorry for what might be an FAQ, but can you use more than one thread while using msieve? If so, what's the proper command for it?[/QUOTE]

-h is your friend. :smile:
From msieve -h:
[CODE]-t <num> use at most <num> threads[/CODE]Note that not all operations are currently able to be multithreaded.

[QUOTE=Mini-Geek;237962]-h is your friend. :smile:
From msieve -h:
[CODE]-t <num> use at most <num> threads[/CODE]Note that not all operations are currently able to be multithreaded.[/QUOTE]

Ah, thanks. Is this placed in the file where the number to be factored is?

.. New (personal) record(?) for largest number factored, using ECM alone;

86229339801531617891831457738571589954220336672017171494473111387369807457745518549587104321020559, was split into:
9718861371938934531518644129 * 8872370589676254655649824600732500550515117106932992561896988884890671.

In the meantime, I'll try using ECM on a number of the form p^n, where p is prime;

I will use 95073391004784128912711766271532202619^3, or 859363596928113044181922356350379552940370289056898128253811986832399424760212777288750086152706299079127416742659.

[QUOTE=3.14159;237963]Ah, thanks. Is this placed in the file where the number to be factored is?

.. New (personal) record(?) for largest number factored, using ECM alone;

86229339801531617891831457738571589954220336672017171494473111387369807457745518549587104321020559, was split into:
9718861371938934531518644129 * 8872370589676254655649824600732500550515117106932992561896988884890671.

In the meantime, I'll try using ECM on a number of the form p^n, where p is prime;

I will use 95073391004784128912711766271532202619^3, or 859363596928113044181922356350379552940370289056898128253811986832399424760212777288750086152706299079127416742659.[/QUOTE]

On the above, it didn't immediately recognize it as a prime power. There should be something to catch a prime power.

I tried using SIQS, to see if it would catch that it was a number of the form p[sup]n[/sup].

Results:
[code]>> siqs(859363596928113044181922356350379552940370289056898128253811986832399424760212777288750086152706299079127416742659)


starting SIQS on c114: 859363596928113044181922356350379552940370289056898128253811986832399424760212777288750086152706299079127416742659

==== sieving in progress ( 4 threads): 304064 relations needed ====
==== Press ctrl-c to abort and save state ====
[/code]

.. Tried the same w/GMP-ECM. It didn't immediately catch it as such either.

By the way; Is that project about factoring sigma(p^n) still active?

[QUOTE=3.14159;237983]Tried the same w/GMP-ECM. It didn't immediately catch it as such either.[/QUOTE]

Odd, isn't it, that an ECM program would run ECM curves rather than detecting if a number is a perfect power.

[QUOTE=CRGreathouse;238028]Odd, isn't it, that an ECM program would run ECM curves rather than detecting if a number is a perfect power.[/QUOTE]

Are you making laughable statements ?

[QUOTE=CRGreathouse;238028]Odd, isn't it, that an ECM program would run ECM curves rather than detecting if a number is a perfect power.[/QUOTE]

I don't need your meaningless sarcasm..

The largest split I've done today;

5033844143885372027408530219404495142062957042044896658482934984273473395896485383398087 can be expressed as..
55142677216152829111571294528236299932749631 * 91287626898369355743182721817195029989331577
Soon to be replaced by a c95. (I'll report back w/factors in ≈60-75 minutes.)

[QUOTE=3.14159;238032]I don't need your meaningless sarcasm..[/QUOTE]

You'll get that about the same time you stop making ridiculous comments. :lol:

[QUOTE=CRGreathouse;238069]You'll get that about the same time you stop making ridiculous comments. :lol:[/QUOTE]

How was it ridiculous? Oh, wait, you're obviously infallible. :rolleyes:

If you have nothing to add but smart-assed comments, just take a hike. Go kick some rocks. [B]Get lost.[/B]

-------------------------------------------------------------

And, the split I was waiting for;

[code]starting SIQS on c95: 46841064479706362242009239768661696640259680130429637064776609553939726832118289550545198006023

==== sieving in progress ( 4 threads): 84528 relations needed ====
==== Press ctrl-c to abort and save state ====
85338 rels found: 21435 full + 63903 from 1174005 partial, (473.94 rels/sec)

SIQS elapsed time = 2587.6930 seconds.


***factors found***

PRP48 = 987044774093075878551222112255952559665853921239
PRP47 = 47455865943614596177273605697112936809372568657[/code]

(The timing isn't too accurate; The total time should have been somewhere around 55-65 minutes.)

Okay; Now I see the problem with the crashing; I'm supposed to use 64-bit YAFU for large factoring jobs.

P.S: My factors! They're there! :smile:

[code]starting SIQS on c102: 598913786496676879646847684910753405454458067319718781528903247886083067885539845621954730905822163869

==== sieving in progress ( 4 threads): 123064 relations needed ====
==== Press ctrl-c to abort and save state ====


SIQS elapsed time = 136.5740 seconds.


***factors found***

PRP51 = 948235779757086528363084445862876675364034142714669
PRP51 = 631608508434582689071389212392863397901302351306801[/code]

.. Setting me a new record.

A C102 factored with yafu in SIQS-mode in 136 seconds?

[QUOTE=kar_bon;238112]A C102 factored with yafu in SIQS-mode in 136 seconds?[/QUOTE]

Nono, the relations were collected separately. A more accurate timeframe would be five hours, + 136 seconds for the [B]post-processing[/B]. (Took up about 1.4 GB of RAM) I forgot to include that. You should have been able to see that, as it did not print the amount of relations it collected.

Though, a 102-digit number in two minutes; I think that would enable me to break an RSA key. (Or maybe not.)

[QUOTE=3.14159;238072]How was it ridiculous?[/QUOTE]

Expecting a tool designed to do A to instead do B? :ermm:

[QUOTE=3.14159;238072]If you have nothing to add but smart-assed comments, just take a hike. Go kick some rocks. [B]Get lost.[/B][/QUOTE]

Good luck with that.

[QUOTE=3.14159;238114]Though, a 102-digit number in two minutes; I think that would enable me to break an RSA key. (Or maybe not.)[/QUOTE]

The current 'insecure; do not use' RSA key length is 1024 bits = 308 digits, about 17 million times harder.

[QUOTE=CRGreathouse]Expecting a tool designed to do A to instead do B?
[/QUOTE]

You misunderstood what I meant.


[QUOTE]The current 'insecure; do not use' RSA key length is 1024 bits = 308 digits, about 17 million times harder.
[/QUOTE]

They might be viable for a couple of decades, IMO.

[QUOTE=3.14159;238140]You misunderstood what I meant.[/QUOTE]

Please, enlighten us.


[QUOTE=3.14159;238140]They might be viable for a couple of decades, IMO.[/QUOTE]

You would trust a 1024-bit RSA key?

[QUOTE=CRGreathouse;238143]Please, enlighten us.




You would trust a 1024-bit RSA key?[/QUOTE]

The former: A power check would be necessary, in order to avoid wasted time.

The latter: Please show me a link which shows the factors of RSA1024.

[QUOTE=3.14159;238145]The former: A power check would be necessary, in order to avoid wasted time.
[/QUOTE]

No. It's your turn to check of powers first. ECM is designed to test in another way.

[QUOTE=kar_bon;238146]No. It's your turn to check of powers first. ECM is designed to test in another way.[/QUOTE]

Wait.. Isn't it supposed to be unable to factor p^n, where p is prime?

(Ex: 5808458716416796798459^5)

I'm going to work on sigma(71608085354600097239391307^4).

[QUOTE=3.14159;238145]The former: A power check would be necessary, in order to avoid wasted time.[/QUOTE]

Do you want it to do trial division by small primes, some rho and SQUFOF, and a probable-prime test too, in case you forgot to do those? How about stopping ECM at some point and switching to a general-purpose factoring algorithm like SIQS?

:lol:

[QUOTE=3.14159;238145]The latter: Please show me a link which shows the factors of RSA1024.[/QUOTE]

So just because no one has made the factors of a particular composite public, you feel safe assuming no one can find the factors?

And of course when you're using an RSA key you're looking to keep it secret in the future, not the past.

But hey, maybe your security just isn't valuable enough to protect.

sigma(71608085354600097239391307^4) took an hour to factor via SIQS. The disappointing part is, that the cofactor's factors were a p7, p18, and p77. It's a surprise that ECM missed a p7 and a p18.

[QUOTE=3.14159;238166]sigma(71608085354600097239391307^4) took an hour to factor via SIQS. The disappointing part is, that the cofactor's factors were a p7, p18, and p77. It's a surprise that ECM missed a p7 and a p18.[/QUOTE]

Pari took 2.15 seconds on my machine to factor that number.

[QUOTE=3.14159;238166]sigma(71608085354600097239391307^4) took an hour to factor via SIQS. The disappointing part is, that the cofactor's factors were a p7, p18, and p77. It's a surprise that ECM missed a p7 and a p18.[/QUOTE]

You'd have to do a very VERY small amount of ECM, or be impossibly unlucky, to miss a p7 and p18. I think most likely, this number was never ECM'd.

For me, it was the latter, for YAFU's ECM. PARI's ECM factored it with ease.

And, about QS; How does the comp determine the amount of relations that are necessary to factor a number?

An example would be the number 2802104782336128351749706435932730996816588058828391669. SIQS reports the following, "2312 relations needed". :huh:

I've recently taken on learning something about how it works. I know the very basic stuff about it, but not much else.

[QUOTE=3.14159;238187]For me, it was the latter, for YAFU's ECM. PARI's ECM factored it with ease.[/QUOTE]

AFAIK, YAFU doesn't ECM at all before running SIQS if you tell it to run with the siqs() command. If you use the factor() command, then it runs ECM and should've found the factors.

[QUOTE=Mini-Geek;238190]AFAIK, YAFU doesn't ECM at all before running SIQS if you tell it to run with the siqs() command. If you use the factor() command, then it runs ECM and should've found the factors.[/QUOTE]

Indeed. siqs(n) goes directly to the quadratic sieve. In factor(n), SIQS is pretty much the "last resort" method, should trial division, Fermat's, Rho, P+1(?), and ECM all fail to factor the number completely. Though, it's still puzzling that it missed a p7 and a p18. I would have expected it to at least be present as a composite, the product of the p7 and p18.

(?) = "Does it use P+1"?

[QUOTE=3.14159;238192]Indeed. siqs(n) goes directly to the quadratic sieve. In factor(n), SIQS is pretty much the "last resort" method, should trial division, Fermat's, Rho, P+1(?), and ECM all fail to factor the number completely. Though, it's still puzzling that it missed a p7 and a p18. I would have expected it to at least be present as a composite, the product of the p7 and p18. [/QUOTE]

I'm not sure what you were expecting if you just ran SIQS. The only thing SIQS does prior to sieving is check for small factors (it does trial division up to 10k, IIRC) and perfect squares. After that, it will not find any factors until sieving, linalg, and sqrt are complete.

[QUOTE=3.14159;238192]

(?) = "Does it use P+1"? [/QUOTE]

yes, factor() uses P+1 with three different random bases. default B1= 20,000.

[QUOTE=CRGreathouse;238171]Pari took 2.15 seconds on my machine to factor that number.[/QUOTE]

I know this is the pari/gp thread, but here's a gratuitous yafu plug:

[CODE]11/21/10 20:31:08 v1.20 @ AVA-343686, System/Build Info:
Using GMP-ECM 6.3, Powered by GMP 5.0.1
detected AMD Phenom(tm) II X4 955 Processor
detected L1 = 65536 bytes, L2 = 6291456 bytes, CL = 64 bytes
measured cpu frequency ~= 3209.987220

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


>> factoring 262934907404708576862758446841091336882604808443805210895581843776020374194863215112535
94913093697297001

div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 1, starting 1000 iterations on C102
rho: x^2 + 3, starting 1000 iterations on C102
rho: x^2 + 2, starting 1000 iterations on C102
pp1: starting B1 = 20K, B2 = 1M on C102
pm1: starting B1 = 100K, B2 = 5M on C95
[B]Total factoring time = 0.3290 seconds[/B]


***factors found***

P3 = 211
PRP7 = 2487811
PRP18 = 887712475607927971
PRP77 = 56425586867064181439411544449942718884745465011098050341509361224221109755611[/CODE]

looks like rho found the p7, and P-1 found the P18.

errr, sorry. P+1 found the p7.

[SIZE="1"]ran out of edit time...[/SIZE]

[QUOTE=bsquared;238202]errr, sorry. P+1 found the p7.

[SIZE="1"]ran out of edit time...[/SIZE][/QUOTE]

... Isn't editing time one hour? It;s only been 23 minutes since you made the post.

I noted the source of the problem. Another difference between 32/64 bit programs.

[QUOTE=bsquared;238201]I know this is the pari/gp thread, but here's a gratuitous yafu plug:[/QUOTE]

Yafu is great, I recommend it. If all you want is factorization, that's a good way to go; Pari's not going to beat it. Pari is useful if you want to do more than factor.

For small jobs like this, it's faster for me to use Pari (already open) than open a new command window to start Yafu.

[QUOTE=CRGreathouse;238212]Pari is useful if you want to do more than factor.
[/QUOTE]

Without a doubt. And as you say, its useful for a good bit of factoring too.

[QUOTE=bsquared;238213]Without a doubt. And as you say, its useful for a good bit of factoring too.[/QUOTE]

Yes. It's optimized for small numbers, though.

Oddly, it seems to have the best primality-proving routine for a certain range of numbers (ending perhaps around 2000 digits). This is strange since the implementation is so simple... maybe no one else thinks APR-CL is worth coding? But it doesn't have ECPP so it can't handle large numbers at all.

[QUOTE=CRGreathouse;238214]Yes. It's optimized for small numbers, though.

Oddly, it seems to have the best primality-proving routine for a certain range of numbers (ending perhaps around 2000 digits). This is strange since the implementation is so simple... maybe no one else thinks APR-CL is worth coding? But it doesn't have ECPP so it can't handle large numbers at all.[/QUOTE]

Well, have any comparisons sprung up? Or is this your personal observation?

And; Record split (Part 2)

[code]starting SIQS on c104: 71885785156901943556739397830381766275419272467038451535302631621686290631421871555186244812363954379653

==== sieving in progress ( 4 threads): 143064 relations needed ====
==== Press ctrl-c to abort and save state ====
143252 rels found: 33431 full + 109821 from 2158034 partial, ( 78.07 rels/sec)

SIQS elapsed time = 28285.8430 seconds.


***factors found***

PRP52 = 9669967622196083512145715713314973785746175999105397
PRP52 = 7433922011475818157575199774990618693040720042141649[/code]

Speaking of PARI/GP, is development of the program still active?

[QUOTE=3.14159;238238]Well, have any comparisons sprung up? Or is this your personal observation?[/QUOTE]

I've timed it against a number of different programs to come up with that. I don't have timings handy, though, so I left the precise statement vague.

[QUOTE=3.14159;238243]Speaking of PARI/GP, is development of the program still active?[/QUOTE]

Absolutely. Actually the last few months are arguably the most productive in terms of development since the initial development. There have been major improvements to core functions, the addition of first-class functions, and some nice tweaks to functions like setsearch. Also some new functions have been added, like printf and alarm.

Unfortunately there have been some troubles of late with Pari.exe, the Windows installer. To get the latest features on Windows one must either download the daily SVN build or build the binary from source. :no:

If I get the time I might look into this, since there are many Windows users who lack the expertise to build the binary on their own but who might benefit from the additional features.

Well, are there going to be new binaries sometime soon? The most recent PARI I've seen is 2.4.2.

[QUOTE=3.14159;238296]Well, are there going to be new binaries sometime soon? The most recent PARI I've seen is 2.4.2.[/QUOTE]

I just discussed that in my last post. There are already new SVN binaries on the site that you can download. But there isn't a new installer, and won't be in the near future, due to difficulties with Vista, Win7, and cygwin/mingw/perl on those systems.

Finding skilled Windows programmers willing to work for free isn't that easy.

[QUOTE=CRGreathouse;238299]I just discussed that in my last post. There are already new SVN binaries on the site that you can download. But there isn't a new installer, and won't be in the near future, due to difficulties with Vista, Win7, and cygwin/mingw/perl on those systems.

Finding skilled Windows programmers willing to work for free isn't that easy.[/QUOTE]

I have a windows system I'm not for pay but I suck lol.

[QUOTE=science_man_88;238300]I have a windows system I'm not for pay but I suck lol.[/QUOTE]

Well, the way to get better (of which the first stage is starting to not suck) is to program, and a great way to do that is to work on an open-source program like Pari. This particular task is probably too hard for you, but one may come along that is appropriate.

The best part of working on these systems is that it's a great way to advertise your skills to potential employers. You can say that you worked on the project and then show your actual contributions.

[QUOTE=CRGreathouse;238299]I just discussed that in my last post. There are already new SVN binaries on the site that you can download. But there isn't a new installer, and won't be in the near future, due to difficulties with Vista, Win7, and cygwin/mingw/perl on those systems.

Finding skilled Windows programmers willing to work for free isn't that easy.[/QUOTE]

Yeah, but those binaries are tarballs. Unusable.

[QUOTE=3.14159;238304]Yeah, but those binaries are tarballs. Unusable.[/QUOTE]

You're downloading the wrong thing.

[QUOTE=Charles;238305]You're downloading the wrong thing.[/QUOTE]

Well, please link to the "correct" items.

[QUOTE=3.14159;238308]Well, please link to the "correct" items.[/QUOTE]

Really? It's right on the download page!

[ATTACH]5917[/ATTACH]

[QUOTE=CRGreathouse;238313]Really? It's right on the download page!

[ATTACH]5917[/ATTACH][/QUOTE]

Oh. Didn't see that. Thanks.

[QUOTE=3.14159;238314]Oh. Didn't see that. Thanks.[/QUOTE]

No problem. You should put the binary in a directory with the .gprc file (probably C:\Program Files\PARI or C:\Program Files (x86)\PARI) or you won't get the colors, default primelimit, etc. from that file.

Unfortunately readline and the high-resolution graphics aren't included in that version AFAIK. I'd like to see that fixed; if I have a chance maybe I'll look into it. But that probably won't happen until next year -- I have a lot of consulting work to do these next few months.

I'm not sure if I even got to explore all of PARI's features as of yet. I know a bit of programming, some number theoretic functions, and how to somewhat randomly generate semiprime or prime numbers.

a(n) = My prime-generating function.

[CODE]lucaslehmer(p)= s=4;for(x=1,p-2,s=(s^2-2)%(2^p-1));if(s==0,return(1),return(0))[/CODE]

my best code so far not that it matters.

[QUOTE=science_man_88;238383][CODE]lucaslehmer(p)= s=4;for(x=1,p-2,s=(s^2-2)%(2^p-1));if(s==0,return(1),return(0))[/CODE]

my best code so far not that it matters.[/QUOTE]

[CODE]lucaslehmer(p)= s=Mod(4, 2^p-1);for(x=1,p-2,s=s^2-2);if(s==0,1,0);[/CODE]
Some small changes.