Sometimes, when I like to play around with primo, I download some PRP from the factoring DB, certificate them and upload the certificate back to the DB.

Normally that works quite fine, but now I have 2 primes, where the certificate just disappears. There is no message that they are rejected. The DB seems not start checking the certificate and the candidates remain PRP. I verified the certificate with PRIMO, so the candidates are indeed prime. Even if I put both into a zip and upload it, it recognizes the 2 certificates but is not processing them.

Does anyone have an idea, what the problem could be?

The candidates are about 1200 digits:
2^3982-245
2^3990-335

attachment: 2 certificates in a zip file.
you can delete that attachment after the problem is solved to save storage of the forum.

This problem was reported one month ago and is not resolved.
Possible bug with 2^a-b numbers?

[URL]http://factordb.com/index.php?id=1100000000217043259[/URL]

[QUOTE=lorgix;260034][URL]http://factordb.com/index.php?id=1100000000217043259[/URL][/QUOTE][url]http://factordb.com/index.php?id=1210004[/url]

Is there a page size limit for Report Results > Report Factors? Or a long delay on large background loads?

I'm trying to synchronize my oddperfect database with factordb. The easy thing was to make some long lists of the form (p^q-1)/(p-1)=factor, paste the lists into the Report Factors page, and click report. Two of the files were over 50,000 lines, so I clicked background submit. For a while the status page under Insert Queue showed Entried Queued 2, but it has been zero for over an hour now. However, one of my test cases hasn't showed up yet.

I thought it might be a problem with a extra carriage return at the end of the file. I've noticed that on the Search Page > Report Factors, a blank line at the end results in all the lines being ignored. So I tried resubmitting, being sure there was not a blank line at the end. But the test case is still not showing up. I'm leaning towards a belief the batch is too large - perhaps an IIS limit - but thought I'd ask before hitting the server with more batches experimenting.

William

My insert problem turned out to be user error. My input expressions were not properly formed.

I'd like to see a "perfect power"-checkbox under "More options".

Btw, what is the forum policy on not making any sense?

[QUOTE=lorgix;261283]Btw, what is the forum policy on not making any sense?[/QUOTE]Making sense is desirable but optional.

We've a special garbage bin for senseless but otherwise harmless posts.

Paul

If i try to report the next factor for aliquot sequence 250452 the database do not accept the factors.

Here is the result from the c111 with factmsieve.py
[CODE]Number: c111
N = 181272454297185328744176839073013972753352282510242039389277374656818709145367785491059261782463082094040240919 (111 digits)
Divisors found:
r1=783497871215194504982057381466887344689071618501303933 (pp54)
r2=231363046355230329033813358171851544135597604061709764643 (pp57)
Version: Msieve v. 1.48
Total time: 11.97 hours.
Factorization parameters were as follows:
n: 181272454297185328744176839073013972753352282510242039389277374656818709145367785491059261782463082094040240919
Y0: -1662360288660249639672
Y1: 446812354453
c0: -3995141492262010049450365
c1: 2032485866657225489791
c2: 1418328127953627500
c3: 104427956031276
c4: -2712208580
c5: 14280
skew: 21101.48
type: gnfs
Factor base limits: 3200000/3200000
Large primes per side: 3
Large prime bits: 27/27
Sieved algebraic special-q in [0, 0)
Total raw relations: 8255754
Relations: 547786 relations
Pruned matrix : 333627 x 333854
Polynomial selection time: 0.00 hours.
Total sieving time: 11.49 hours.
Total relation processing time: 0.09 hours.
Matrix solve time: 0.25 hours.
time per square root: 0.13 hours.
Prototype def-par.txt line would be: gnfs,110,5,61,2000,0.00015,0.3,250,15,50000,2400,3200000,3200000,27,27,50,50,2.6,2.6,100000
total time: 11.97 hours.
x86 Family 6 Model 23 Stepping 6, GenuineIntel
Windows-Vista-6.0.6002-SP2
processors: 2, speed: 2.09GHz
[/CODE]

The Database tell me that the factor do not divide the c111!?

[QUOTE=Andi_HB;261763]If i try to report the next factor for aliquot sequence 250452 the database do not accept the factors.

Here is the result from the c111 with factmsieve.py
[CODE]Number: c111
N = 181272454297185328744176839073013972753352282510242039389277374656818709145367785491059261782463082094040240919 (111 digits)
Divisors found:
r1=783497871215194504982057381466887344689071618501303933 (pp54)
r2=231363046355230329033813358171851544135597604061709764643 (pp57)
Version: Msieve v. 1.48
Total time: 11.97 hours.
Factorization parameters were as follows:
n: 181272454297185328744176839073013972753352282510242039389277374656818709145367785491059261782463082094040240919
Y0: -1662360288660249639672
Y1: 446812354453
c0: -3995141492262010049450365
c1: 2032485866657225489791
c2: 1418328127953627500
c3: 104427956031276
c4: -2712208580
c5: 14280
skew: 21101.48
type: gnfs
Factor base limits: 3200000/3200000
Large primes per side: 3
Large prime bits: 27/27
Sieved algebraic special-q in [0, 0)
Total raw relations: 8255754
Relations: 547786 relations
Pruned matrix : 333627 x 333854
Polynomial selection time: 0.00 hours.
Total sieving time: 11.49 hours.
Total relation processing time: 0.09 hours.
Matrix solve time: 0.25 hours.
time per square root: 0.13 hours.
Prototype def-par.txt line would be: gnfs,110,5,61,2000,0.00015,0.3,250,15,50000,2400,3200000,3200000,27,27,50,50,2.6,2.6,100000
total time: 11.97 hours.
x86 Family 6 Model 23 Stepping 6, GenuineIntel
Windows-Vista-6.0.6002-SP2
processors: 2, speed: 2.09GHz
[/CODE]

The Database tell me that the factor do not divide the c111!?[/QUOTE]

Something went wrong while copying the files to the server. I'm on it!

How can I check a few hundred numbers to learn if factordb has a full factorization? If they are dense in a parametric form, the Factor Tables form is exactly what I want - especially with the "text" and "text, compact" outputs. But if the the numbers are heterogeneous in form, I haven't found anything better than repetitive cut and paste to the Search form. I guess I could write a python script to automate that - are there any better approaches?

William

[QUOTE=cmd;261862]so :

[code]

[B]???? ???? ???? ????[/B]

¿¿¿¿ ¿¿¿¿ ¿¿¿¿ ¿¿¿¿

[I]???? ???? ???? ????[/I]

¿¿¿¿ ¿¿¿¿ ¿¿¿¿ ¿¿¿¿

[B]???? ???? ???? ????[/B]

[/code][/QUOTE]

Can someone please stop this guy from spamming this thread!

He got his own thread to post such things.

Thanks.

[QUOTE=kar_bon;261894]Can someone please stop this guy from spamming this thread!

He got his own thread to post such things.

Thanks.[/QUOTE]I deleted many of his posts in this thread. Didn't check if any of them was useful (which i doubt).

I'll propose a ban if he continues.

Has something changed in the format expected by the DB when submitting factors? As of 3-4 days ago, I could submit a factorization from the command line using a command like this:
[CODE]
wget http://factordb.com/report.php --post-data="report=true&msub=13190789828154072917143593725962464892772345908077188923589296347603204686539531 = 51467689791946698239 * 256292634883683371484524861104319590830984670961919826205429"
[/CODE]But now that doesn't seem to work -- when I query the composite it still shows up as unfactored. If I report the factors manually through the web page, it does work, although I get a strange-looking message like:

[CODE]51467689791946698239: factor already known
51467689791946698239: new factor[/CODE]

Is anyone else having this problem? Am I using the wrong wget command to submit?

[QUOTE=bchaffin;261938]
Is anyone else having this problem? Am I using the wrong wget command to submit?[/QUOTE]

I did a few small changes to the submit form, i think only the variable name changed. But keep your script, I'll make both variables work. Easier this way.

[QUOTE]How can I check a few hundred numbers to learn if factordb has a full factorization?[/QUOTE]

At the moment there is no way to do this with one request.

[QUOTE=Syd;261946]I did a few small changes to the submit form, i think only the variable name changed. But keep your script, I'll make both variables work. Easier this way.[/QUOTE]

Thanks Syd, that was fast -- it's working now.

I changed a few more things, thats:
-the input parser. It may give some error messages, I'm working on it
-ecm/p+1/p-1-results are now also saved. Just copy the whole gmp-ecm output inside the results box
-someone used to flood and fill the database with random numbers, so I put some limits per IP in there. Tell me if they are too low!
-added a little tool to calculate ecm group orders
([url]http://factordb.com/groupcalc.php[/url])

I hope everything is working!

Now I'm going to prp-test all numbers up to at least 10k digits. This will take some time.

[QUOTE=Syd;261984]I changed a few more things, thats:
-the input parser. It may give some error messages, I'm working on it
-ecm/p+1/p-1-results are now also saved. Just copy the whole gmp-ecm output inside the results box
-someone used to flood and fill the database with random numbers, so I put some limits per IP in there. Tell me if they are too low!
-added a little tool to calculate ecm group orders
([URL]http://factordb.com/groupcalc.php[/URL])

I hope everything is working!

Now I'm going to prp-test all numbers up to at least 10k digits. This will take some time.[/QUOTE]

I reached the hourly limit on CPU-time in 58 minutes.

I used to be able to submit things like

[code]
271427466523206484847994068911650639605211252676780737908688140410714736524641091422630657735093035601853065255927575880416555215109540024045933346045786966=2*3^2*7*37*168148369*3203229620049913*1360431734531670131847561541955682301592960850611*79455513541390151139958754790541060250889700879428962184770179563141553469758579
418843675097827265722980539527791853106180383815497669797039425714247050685769210356616440350089340212315250921632616394203641575784352554580820377145329834=2*3^2*7*43*857*210643*908419*3039056421010273*155117263844215027452110925603234757817465496458519899734548941351870914781082539019827558204805397920484658160909905437649
643657055044722845453318200858189786179249238618662777304007190201623142612757306498360771216457869756045243113995195885302297974328444182051312004489742166=2*3^3*7*101*857*1193*1801*1692221*5410648256741139118184621944921333176675429270768776125309616588165637564050976395580889554876497334385323055655980821367054780283818207
[/code]

to the report-factors box, to report an extension of an aliquot sequence. This no longer works - I get an error message 'factor already known', but the sequence does not extend.

The "elf-file" format ("index . composite = factor*factor...") is not accepted anymore!?
So the command "aliqueit -s " does not work for me.
Index and composite merge to one number and so just reporting some (already known) factors and there is no extension of sequences!?

[QUOTE=RobertS;262005]The "elf-file" format ("index . composite = factor*factor...") is not accepted anymore!?
[/QUOTE]

*gulp*
If that's intended, this might make me (and probably others who don'tg want to enter factor by factor manually) quit the aliquot project.

[QUOTE=lorgix;261995]I reached the hourly limit on CPU-time in 58 minutes.[/QUOTE]

No problem, I increased this limit.

[QUOTE=fivemack;262001]I used to be able to submit things like
to the report-factors box, to report an extension of an aliquot sequence. This no longer works - I get an error message 'factor already known', but the sequence does not extend.[/QUOTE]

[QUOTE=RobertS;262005]The "elf-file" format ("index . composite = factor*factor...") is not accepted anymore!?
So the command "aliqueit -s " does not work for me.
Index and composite merge to one number and so just reporting some (already known) factors and there is no extension of sequences!?[/QUOTE]

This was a bug within the new parser. I think I found the bug now, just the output is still a little bit messy.

[QUOTE]*gulp*
If that's intended, this might make me (and probably others who don'tg want to enter factor by factor manually) quit the aliquot project. [/QUOTE]

No, it was not intended!!

[QUOTE=Syd;262020]
No, it was not intended!![/QUOTE]

nice to hear that!

[QUOTE=Syd;261984]-ecm/p+1/p-1-results are now also saved. Just copy the whole gmp-ecm output inside the results box

-added a little tool to calculate ecm group orders
([url]http://factordb.com/groupcalc.php[/url])
[/QUOTE]

The calculator for the group order works great for a couple of test numbers I entered in. And it is pretty quick too. What do you use to calculate the group orders? Is it Pari/GP, something written in GMP, or something else?

Also, when submitting gmp-ecm output, what all should be included? Should it be:
---------------------------------------------------
GMP-ECM 6.3 [configured with GMP 5.0.1] [ECM]
Input number is 189620700613125325959116839007395234454467716598457179234021
Using B1=3000000, B2=5706890290, polynomial Dickson(6), sigma=4282141129
********** Factor found in step 2: 282174488599599500573849980909
Found probable prime factor of 30 digits: 282174488599599500573849980909
Probable prime cofactor 671998030559713968361666935769 has 30 digits
---------------------------------------------------
Or more? Or less?

Also, do you save what version of gmp-ecm was used? And, if someone submits an ecm/p-1/p+1 for an existing number (that either does or does not already have an existing ecm/p-1/p+1 entry), does the new entry overwrite/update the existing factor? Or do you just save this info for new numbers?

[QUOTE=WraithX;262022]The calculator for the group order works great for a couple of test numbers I entered in. And it is pretty quick too. What do you use to calculate the group orders? Is it Pari/GP, something written in GMP, or something else?

Also, when submitting gmp-ecm output, what all should be included? Should it be:
---------------------------------------------------
GMP-ECM 6.3 [configured with GMP 5.0.1] [ECM]
Input number is 189620700613125325959116839007395234454467716598457179234021
Using B1=3000000, B2=5706890290, polynomial Dickson(6), sigma=4282141129
********** Factor found in step 2: 282174488599599500573849980909
Found probable prime factor of 30 digits: 282174488599599500573849980909
Probable prime cofactor 671998030559713968361666935769 has 30 digits
---------------------------------------------------
Or more? Or less?

Also, do you save what version of gmp-ecm was used? And, if someone submits an ecm/p-1/p+1 for an existing number (that either does or does not already have an existing ecm/p-1/p+1 entry), does the new entry overwrite/update the existing factor? Or do you just save this info for new numbers?[/QUOTE]

I use a part of the sage-library to calculate it, its the fastest i could find.

I only save the sigma, b1/b2 bounds, submission time and the user (if logged in). There can only be one ecm/p+1/p-1-result per prime, and thats the one submitted first. I store this not only for new primes, also on already existing numbers.

You can either paste the gmp-ecm output inside the report box (needs input number, prime found + parameters in it) or open the ecm-window on this number and enter the parameters manually. I tested this for quite a few numbers/outputs, so hopefully its bugfree

Doesn't work for factors found with Brent-Suyama's extension, right?

[QUOTE=lorgix;262028]Doesn't work for factors found with Brent-Suyama's extension, right?[/QUOTE]

No, not yet.

OK. Sounds like you're working on that(?)

Would it be realistic, btw, to do some basic ecm/p+1/p-1 automatically? Like TF.


p.s. Great work with the db, I really appreciate it!

For numbers less than 50 digits it's easy enough to grab thousands at once to batch process but for numbers greater than 50 digits, is there any way to get large quantities of them at once? Or just one at a time? Might be a nice feature to put in sometime.

Any chance that factors that were submitted for sequences be redone on your end? I had a hard drive crash and lost several days of data.

[QUOTE=lorgix;262031]OK. Sounds like you're working on that(?)
[/QUOTE]

Thats something I have to read more about first.

[QUOTE]
Would it be realistic, btw, to do some basic ecm/p+1/p-1 automatically? Like TF.
[/QUOTE]

On small numbers - of cause. At least P-1, B1=20k for all numbers <400 digits sounds okay to me. But this needs some more changes - give me a week or so.

[QUOTE]
p.s. Great work with the db, I really appreciate it![/QUOTE]

Thank you :smile:

[QUOTE=mnh001;262035]For numbers less than 50 digits it's easy enough to grab thousands at once to batch process but for numbers greater than 50 digits, is there any way to get large quantities of them at once? Or just one at a time? Might be a nice feature to put in sometime.[/QUOTE]

You could either use listtype.php - or - the script I just placed within the download-section. Max. is 5k at once. Enough? But at the moment you will just get some of the random numbers someone spammed in there ..

[QUOTE=ugly2dog;262036]Any chance that factors that were submitted for sequences be redone on your end? I had a hard drive crash and lost several days of data.[/QUOTE]

Redone? If you submitted them, you can get em back. Or did I not understand your question?

[QUOTE=cmd;262055]_.[/QUOTE]

100k useful numbers?!? :rant:

[QUOTE=Syd;262050]...But at the moment you will just get some of the random numbers someone spammed in there ...[/QUOTE]
I hope those aren't residual from my sociable number search around 10^15 a week or so ago. I was using AliWin/Aliqueit and was bumping the db to see if the sequences might already exist, which caused it to initiate and run the sequences based on the primary number. Then the sequences took off on their own generating more composites. I stopped querying the db as soon as I realized it was running away with the sequences. I would have thought that they would have cleared by now, but maybe not.

Sorry, if I was that source of the "random" numbers. It was neither foreseen nor intentional.

I wonder if it might not actually be good to have the db initiate an aliquot sequence simply by querying for a non-existent one...

@EdH

no, its okay to create sequences. These random numbers have no sequence assigned, so I guess you did not cause those numbers.

Ah, great. Thanks.

OBTW, I like the way you've done the database. Good job.

It's great to see the ECM factor's sigma and group order in the database now.

This number is ready for a combined N+1, N-1 primality proof, but clicking the button doesn't seem to create the proof.

http://factorization.ath.cx/index.php?query=%284931^101-1%29%2F408298275980810

[QUOTE=wblipp;262160]This number is ready for a combined N+1, N-1 primality proof, but clicking the button doesn't seem to create the proof.

http://factorization.ath.cx/index.php?query=%284931^101-1%29%2F408298275980810[/QUOTE]

It was already proved prime via Primo on May 3, 2011.
No need to re-prove it again.

[QUOTE=wblipp;262160]This number is ready for a combined N+1, N-1 primality proof, but clicking the button doesn't seem to create the proof.

http://factorization.ath.cx/index.php?query=%284931^101-1%29%2F408298275980810[/QUOTE]

It needs more factoring, the output says:

[QUOTE]Calling N-1 BLS with factored part 21.76% and helper 16.55% (82.10% proof)[/QUOTE]

besides that, its already proven.

So how fast is your local worker factoring the under-70 composites? In order to help clear out some of the cruft I've started running msieve on the "small composite list" (download, run msieve for a while, upload, re-download). I'm just wondering how often I should upload so as to not duplicate too much work.....

[QUOTE=Syd;262056]100k useful numbers?!? :rant:[/QUOTE]That would be my question: does there appear to be any [URL="http://www.phrases.org.uk/meanings/377000.html"]method[/URL] there or just madness?

[QUOTE=schickel;262203]So how fast is your local worker factoring the under-70 composites? In order to help clear out some of the cruft I've started running msieve on the "small composite list" (download, run msieve for a while, upload, re-download). I'm just wondering how often I should upload so as to not duplicate too much work.....
[/QUOTE]

Its just one core @idle priority now. As most of them have small factors and only a few require sieving its on average ~2 seconds each. Here are some statistics whats left:

[CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;
+--------+-------+
| digits | n |
+--------+-------+
| 60 | 20718 |
| 61 | 280 |
| 62 | 303 |
| 63 | 312 |
| 64 | 333 |
| 66 | 15 |
| 67 | 15 |
| 68 | 13 |
| 69 | 38 |
| 70 | 48 |
| 71 | 251 |
| 72 | 240 |
| 73 | 215 |
| 74 | 154 |
| 75 | 170 |
| 76 | 512 |
| 77 | 644 |
| 78 | 638 |
| 79 | 602 |
| 80 | 693 |
| 81 | 765 |
| 82 | 872 |
| 83 | 938 |
| 84 | 954 |
| 85 | 931 |
| 86 | 989 |
| 87 | 974 |
| 88 | 957 |
| 89 | 920 |
| 90 | 834 |
| 91 | 770 |
| 92 | 668 |
| 93 | 600 |
| 94 | 694 |
| 95 | 721 |
| 96 | 1218 |
| 97 | 14914 |
| 98 | 17828 |
| 99 | 20363 |
+--------+-------+
39 rows in set (0.04 sec)
[/CODE]

[QUOTE=Syd;262205]Its just one core @idle priority now. As most of them have small factors and only a few require sieving its on average ~2 seconds each. Here are some statistics whats left:

[CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;

[ snip ]

[/CODE][/QUOTE]So >60,000 numbers that are <100 digits?

:sad: :no: :cry:

I'm using the factoring-script DByafu.pl from [url=http://www.mersenneforum.org/showpost.php?p=230762&postcount=894]here[/url] to help, getting rid of those small numbers.

[QUOTE=cmd;262249]we do not understand, can someone "explain|clarify"
where we make mistakes in [B]your[/B] approach ?


[COLOR=LemonChiffon]( We inadvertently, sometimes ... to have the fingers of his hand quicker than eye )
[/COLOR][/QUOTE]

Looking at those numbers I would say that you have added 1e5 small numbers using Factor tables. Right?

That makes people wonder what those numbers are. Especially since someone apparently added thousands of seemingly random numbers.

Edit: Ehmm... Did you just make ~400 additional page requests just to get the total number up to 666?!

You're not making much sense.

Do the translation before you post. Hopefully that will help.

If you're saying that you're adding all prime numbers, let's get some perspective;

Right now the db contains about 4.6*10^8 numbers, which is roughly equal to the number of primes [B]9 digits or smaller[/B].

Edit: I tried... Wont bother with this anymore.

[QUOTE=cmd;262249]we do not understand, can someone "explain|clarify"
where we make mistakes in [B]your[/B] approach ?
[/QUOTE]

Hello cmd, the reason you are seeing this message is because your activities are putting too many new numbers into the factordb. This limit has been put in place as a nice way of asking people to not flood the factordb with new numbers.

My question is, what is your goal? Are you trying to factor numbers of a certain form? Are you trying to find numbers with a certain property? If you are trying to factor numbers of a special form, I'd recommend using either yafu or msieve. They are both excellent programs. This way, you can continue your mathematical activities without putting a burden on the factordb. If you need help running/using either yafu or msieve, you can open a new thread where we can answer your questions. In any case, I'd like to ask you to stop using the factordb like you are currently using it.

[CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;[/CODE]

This might be an interesting stat. Should a link to a Small Composites [strike]Status[/strike] Summary page be available which is updated periodically?

[QUOTE=RichD;262277][CODE]mysql> select digits, count(digits) as n from C where digits<100 group by digits having n>10;[/CODE]

This might be an interesting stat. Should a link to a Small Composites [strike]Status[/strike] Summary page be available which is updated periodically?[/QUOTE]

Just as a quick dirty hack:
[url]http://factordb.com/stat_1.php[/url]
The query is fast, there's no need to cache it. Btw, left the n>10 out :smile:

[QUOTE=Syd;262291]Just as a quick dirty hack:
[url]http://factordb.com/stat_1.php[/url]
The query is fast, there's no need to cache it. Btw, left the n>10 out :smile:[/QUOTE][quote=factorDB][B]SIZE COUNT[/B]
60 1,195
61 1,286
62 1,326
63 1,308 [/quote]Nice to see that the 60-digit stuff has been (mostly) cleared....

[QUOTE=kar_bon;262234]I'm using the factoring-script DByafu.pl from [url=http://www.mersenneforum.org/showpost.php?p=230762&postcount=894]here[/url] to help, getting rid of those small numbers.[/QUOTE]I'm using a manual upload method since then I don't have to install anything; and if I use a computer that I don't have regular access to, I can just blast through a few numbers when I get a chance.

[QUOTE=cmd;262295]?19[/QUOTE]Why 19 digirts?

Becuase [I]someone[/I] :whistle: is loading [B]thousands[/B] of numbers into the DB. As the DB workers run ECM curves, those small numbers are the leftovers that have to factored....

[QUOTE=lorgix;262031]Would it be realistic, btw, to do some basic ecm/p+1/p-1 automatically? Like TF.[/QUOTE]

Will that become reality?

Btw, are all scan levels necessary? The first is ridiculously fast. And ECM to low bounds is exhausted with only a few curves, I think.

JpGraph Error: 25068
 

Looking at HP[SUB]10[/SUB](49) I clicked 'Show huge graph'.

That brought me to [URL]http://factordb.com/aliquot.php?type=10&aq=7&big=1[/URL]

And this image was displayed;

Seems like someone just put a few thousand RSA-1024 into the db...

Why is there interest in finding the complete factorization of 136^35+n for n odd 1 to one million, and 2^1024+n, n 1 to 1000? It appears both of these sets have been dumped into factordb this week.

[QUOTE=wblipp;264472]Why is there interest in finding the complete factorization of 136^35+n for n odd 1 to one million, and 2^1024+n, n 1 to 1000? It appears both of these sets have been dumped into factordb this week.[/QUOTE]I figured our [URL="http://www.mersenneforum.org/member.php?u=8872"]friend[/URL] has been (hyper)active again....

Fatal error
 

[CODE]Fatal error: Call to a member function __getgmp() on a non-object in /apache/htdocs/factor.php on line 538[/CODE]

[QUOTE=lorgix;263293]
"Would it be realistic, btw, to do some basic ecm/p+1/p-1 automatically? Like TF."
Will that become reality?

Btw, are all scan levels necessary? The first is ridiculously fast. And ECM to low bounds is exhausted with only a few curves, I think.[/QUOTE]

Anyone have an opinion on this?

see also ( 25068-8/2 )
 

[QUOTE=lorgix;263863]Looking at HP[SUB]10[/SUB](49) I clicked 'Show huge graph'.

That brought me to [URL]http://factordb.com/aliquot.php?type=10&aq=7&big=1[/URL]

And this image was displayed;[/QUOTE]

2506[B]4[/B]

[QUOTE=lorgix;266061]Anyone have an opinion on this?[/QUOTE]

I think the DB already does some work in the background on all composites. I have a script which slowly walks through open aliquot sequences to keep my local list up to date, and it often finds that, for example, a c110 has "spontaneously decayed" into a p15 and a c95, without adding any terms to the sequence. Surely this is not a human going to the trouble of submitting a partial factorization (is it?). So it seems to me that the DB must be doing a little testing which occasionally finds factors up to about 20 digits.

I just put a small update online:

-now it does P-1 to B1=25k on every incoming number <400 digits
-the first click on the scan-button runs 2 levels at once
-some small bugfixes (HP 49 bug, certificate bug, some more)
-snfs poly generator (just as an experiment)
-next prime above N
and some more.

Hope everything is working (and I left no debugging code in :smile: )

[QUOTE=bchaffin;266113]I think the DB already does some work in the background on all composites. I have a script which slowly walks through open aliquot sequences to keep my local list up to date, and it often finds that, for example, a c110 has "spontaneously decayed" into a p15 and a c95, without adding any terms to the sequence. Surely this is not a human going to the trouble of submitting a partial factorization (is it?). So it seems to me that the DB must be doing a little testing which occasionally finds factors up to about 20 digits.[/QUOTE]

I ran a few curves with very low limits on all the composites below 150 digits, just to get the very small factors, maybe that found the p15.

Nice changes!

Weird btw: search for 99,738 on the page below.

[URL]http://factordb.com/show_config.php[/URL]

Syd, would it be possible to add another stats query like the "stat_1.php" for composites, but list the PRPs instead?

I noticed the DB being laggy while uploading some sequence results and a little snooping shows that someone has apparently dumped in 1,000s of mid-20 digit PRPs that are taking a while to clear......I found 3 pages of 1000 at the 21-digit level.

[Edited to add: Make that 10s of 1,000s. There are >10,000 PRPs between 22 and 26 digits right now.]

Using the "More Information" button, you can see that the PRPs were not entered directly. They come from factoring a large number of composites recently entered. They do not seem to have any particular structure.

[QUOTE=wblipp;266551]Using the "More Information" button, you can see that the PRPs were not entered directly. They come from factoring a large number of composites recently entered. They do not seem to have any particular structure.[/QUOTE]It looks like they cleared out faster than I thought they were.

I had uploaded <10 lines of a sequence and the ~40 digit factors were still marked as PRP after 10 minutes or so. It looks like the queue has cleared now.....I just panicked thinking we had someone flooding the DB with useless numbers again.

[QUOTE=lorgix;266355]Nice changes!

Weird btw: search for 99,738 on the page below.

[URL]http://factordb.com/show_config.php[/URL][/QUOTE]

Thank you! These limits were determined by experiment, so they are not 100% accurate. But they dont need to be.

[QUOTE=schickel;266546]Syd, would it be possible to add another stats query like the "stat_1.php" for composites, but list the PRPs instead?
[/QUOTE]

Sure:

[url]http://factordb.com/stat_1.php?prp[/url]

[QUOTE=Syd;266592]Thank you! These limits were determined by experiment, so they are not 100% accurate. But they dont need to be.



Sure:

[url]http://factordb.com/stat_1.php?prp[/url][/QUOTE]Thanks for that!

BTW, in case I haven't said it this week yet, great resource you have....it's making things over at the Aliquot forum very easy to manage!

The DB is being incredibly slow and is getting lots of "server is taking too long to respond" errors on Firefox. Is someone dumping loads of useless numbers into the DB again?

[QUOTE=10metreh;268485]The DB is being incredibly slow and is getting lots of "server is taking too long to respond" errors on Firefox. Is someone dumping loads of useless numbers into the DB again?[/QUOTE]
At this time, for me, all seems fine - normal (quick) response time, about 22M composites without known factors... [Fedora - Firefox]

How actual the "Smallest numbers without known factors (sorted by digits only)" are? I have no idea about the things you are talking here, and where that numbers are coming from (I did not read all the thread, just followed last links) but some of that numbers seems quite easy to factor (under 100 digits) and I could dedicate some CPU time to factor some of them if they are really needed. For example this one took under 10 minutes on Dario's applet:

[CODE]
4728913920212267541311160316535971501621745162863049097438144927735315373737931=
612275446716620701510495422889598831071 x
7723507361876867225411296165036058400661.
[/CODE](listed on position 2 on the list, 79 digits)

[QUOTE=LaurV;268621]How actual the "Smallest numbers without known factors (sorted by digits only)" are?[/QUOTE]


See [url=http://factordb.com/stat_1.php]here[/url] for the countinge of small composites and [url=http://factordb.com/listtype.php?t=3]here[/url] for a list.

See also [url=http://www.mersenneforum.org/showpost.php?p=230762&postcount=894]this post[/url] for a automated scripts to get, factor and submit those small composites.

PS: The workers of the FactorDB will factor those small composites by time. You can do this best with the script above, or using yafu (it's faster than the applet) manually.

PPS: Sorry, fire :D

This list list all the composite which are not fctored in the db, thats all. there is a script written in perl that grab 100 number of that list, factor them and send them back to the database. you need to have yafu/msieve and wget installed
[code]
#!H:\strawbery\perl
use strict;

print("FactorDB Helper 1.4 with yafu\n");

# wget executable
my $wget = "H:/Docume~1/Vincent/Bureau/script/wget --no-check-certificate";

## min and max number of digits to factor
my $mindig = 5;
my $maxdig = 75;

$| = 1;
$/ = undef;

sub shuffle {
for ( my $i = 0 ; $i < @_ ; $i++ ) {
my $j = rand( @_ - $i ) + $i; # pick random element
( $_[$i], $_[$j] ) = ( $_[$j], $_[$i] ); # swap 'em
}
}

while (1) {

my @todo;

# getting 100 random unfactored numbers
$_ = `$wget -O - "http://factordb.com/getrandom.php?n=100&t=3&mindig=$mindig&maxdig=$maxdig"`;

# or getting 100 smallest unfactored numbers
#$_ = `$wget -O - "http://factordb.com/listtype.php?t=3&scriptmode=1"`;

while (/(\d{19})\s(\d+)/gs) {

my $id = $1;
my $digits = $2;

if ( ( $digits >= $mindig ) && ( $digits <= $maxdig ) ) {
push( @todo, $id );
}
}

print( "Todo size: ", scalar(@todo), "\n" );

if ( scalar(@todo) == 0 ) {
print("No suitable numbers. Resting for a while.\n");
sleep 60;
next;
}

shuffle(@todo);

foreach (@todo) {
my $id = $_;

# checking status and getting the number in decimal
$_ = `$wget -O - http://factordb.com/getnumber.php?id=$id`;
if ( !/(\S+)\s(\d+)/ ) {
print("Error 1\n");
sleep 60;
next;
}

if ( $1 != "C" ) {
print("\nid=$id has known factors / is already factored.\n\n");
next;
}

my $number = $2;
my $digits = length($number);

print("Factoring $digits-digit number (id=$id)\n");

my $yafu = "H:/Docume~1/Vincent/Bureau/script/yafu \"factor($number)\" >joo.log";
system($yafu);

my $text = do { local ( @ARGV, $/ ) = "joo.log"; <> };
print "Num: $number\nResults:\n";
my @results;

my @out = split( "\n", $text );
for (@out) {
if (/P.*? = (\d+)/) {
push( @results, $1 );
print "$1\n";
}
}

unlink "joo.log";

if ( scalar(@results) > 0 ) {
my $factors = join("\n",@results);
$_ = `$wget --post-data "report=$factors&format=0" -O - http://factordb.com/index.php?id=$id`;
}
else {
print("Error 2\n");
sleep 60;
}
}
}
[/code]this code is in the earlier answer of this thread.
edit : damn you kar_bon, damn you!

Thanks both of you. Meantime I figured it out how it works and reported a bunch of the small already (including the one mentioned in my previous post). It is a bit boring to do it by hand, but it is fun and I found it out that it takes about the same time to factor one of the smallest numbers from the database using yafu as it would take to play a freecell game (I am quite a fast player :P) and I will return to this database from time to time when I have nothing to do for a couple of minutes. I believe it is more useful then playing freecell hehe. I bookmarked it.

[QUOTE=LaurV;268625]Thanks both of you. Meantime I figured it out how it works and reported a bunch of the small already (including the one mentioned in my previous post). It is a bit boring to do it by hand, but it is fun and I found it out that it takes about the same time to factor one of the smallest numbers from the database using yafu as it would take to play a freecell game (I am quite a fast player :P) and I will return to this database from time to time when I have nothing to do for a couple of minutes. I believe it is more useful then playing freecell hehe. I bookmarked it.[/QUOTE]

Math can do all !

[QUOTE=LaurV;268621]How actual the "Smallest numbers without known factors (sorted by digits only)" are? I have no idea about the things you are talking here, and where that numbers are coming from (I did not read all the thread, just followed last links) but some of that numbers seems quite easy to factor (under 100 digits) and I could dedicate some CPU time to factor some of them if they are really needed. [/QUOTE]The "smallest composites" are the leftovers from factoring larger numbers. If you click through to a lot of them they have the form ([i]expression[/i])/x/y/z. <[i]expression[/i]> is the original number, while [i]x, y,[/i] & [i]z[/i] are other factors found by various means.

Don't worry about anything under 70 digits, the DB-local workers will factor those quicker than you can download, factor, and upload them.

For numbers over that, you have a couple of options. kar_bon mentioned and firejuggler posted scripts that you can run that factor numbers >70 digits. There are several forum members that do that.

Or you can go to the download tab and grab a larger set. What I do when I have some time on a non-dedicated PC is download the 1000 numbers, trim out the smaller ones, and then run "[b]msieve -e[/b]" against them.

Depending on how much ECM has been run against them by the DB and/or uploader, sometimes you can factor quite a few in a couple of hours...

[QUOTE=schickel;268653]
Don't worry about anything under 70 digits...[/QUOTE]

I don't, because I did not see any. It seems that only "over 70" are added to that list, most probably "under 70" are automatically taken care by the server without adding them to that list. Or at least that was my impression after spending a couple of hours on database yesterday. In fact it is said somewhere there that the exponents under 70 digits are factored by I don't know which machine on that list. So I took care yesterday (gmt+7 here) of everything that appeared under 82 bits. That was fun, and quite suitable task for me, who I am quite impatient and don't like waiting days to see some factors :D

(running yafu and Dario's applet, manually, in "stealing clocks" mode, that means: they don't have their own core, as all cores are busy with other - longer - tasks)

P.S. love your avatar!

[QUOTE=10metreh;268485]The DB is being incredibly slow and is getting lots of "server is taking too long to respond" errors on Firefox. Is someone dumping loads of useless numbers into the DB again?[/QUOTE]

This time it was the googlebot. I had no robots.txt ready to avoid it crawling the page so it also "crawled" lots of scan-buttons. When I logged in on the server the load average was >300, lots of ecm jobs running.
I dont see any need to have the factordb in google, therefore disabled it completely.

[QUOTE=LaurV;268733]I don't, because I did not see any. It seems that only "over 70" are added to that list, most probably "under 70" are automatically taken care by the server without adding them to that list. Or at least that was my impression after spending a couple of hours on database yesterday. In fact it is said somewhere there that the exponents under 70 digits are factored by I don't know which machine on that list. So I took care yesterday (gmt+7 here) of everything that appeared under 82 bits. That was fun, and quite suitable task for me, who I am quite impatient and don't like waiting days to see some factors :D
[/QUOTE]

Smaller numbers can get on that list, but they are factored too quick to be on that list for longer than a few seconds.

I'm wondering if it would make sense to factor some numbers around 90 digits with a good snfs poly using snfs. Just factored (2^298*419+911)/281 (90 digits) as a test, it took ~5 minutes to get 1M relations + 1 minute for postprocessing using msieve, yafu/siqs took >30 minutes.

[QUOTE=LaurV;268733]I don't, because I did not see any. It seems that only "over 70" are added to that list, most probably "under 70" are automatically taken care by the server without adding them to that list. Or at least that was my impression after spending a couple of hours on database yesterday. In fact it is said somewhere there that the exponents under 70 digits are factored by I don't know which machine on that list. So I took care yesterday (gmt+7 here) of everything that appeared under 82 bits. That was fun, and quite suitable task for me, who I am quite impatient and don't like waiting days to see some factors :D[/quote]The composite queue looks to be under control right now. Sometimes, though, the queue can be quite long, with composites down to the mid 30-50 digit range (really only a problem when someone is spamming the factor tables really heavily....)
[quote](running yafu and Dario's applet, manually, in "stealing clocks" mode, that means: they don't have their own core, as all cores are busy with other - longer - tasks)[/quote]Thank you for your contribution. I look on factoring what I can as the toll I pay for the use I get out of the DB (check out the aliquot [url="http://www.mersenneforum.org/forumdisplay.php?f=90"]subforum[/url] to see where I hang my hat).

If you ever want to devote some more time to work that needs doing, let us know. The other nice thing to contribute is primality certificates for primes >300 digits, but those take a bit more time and effort.[quote]P.S. love your avatar![/QUOTE]Thanks, I tried on quite a few before I settled on this one.....some days that's the way I really feel.

PS. I see Syd hit reply a little ahead of me.

[QUOTE=Syd;268736]I'm wondering if it would make sense to factor some numbers around 90 digits with a good snfs poly using snfs. Just factored (2^298*419+911)/281 (90 digits) as a test, it took ~5 minutes to get 1M relations + 1 minute for postprocessing using msieve, yafu/siqs took >30 minutes.[/QUOTE]If you could come up with a quick & easy automated way, I'd say go for it, otherwise it might be quicker/easier to just use msieve or yafu for the small numbers.

When I have my system factoring, I just run msieve in batch mode, since it can sometimes get lucky hits with the "deep ECM" option. Nothing like factoring 80+ digit numbers in <30 secs!

Just out of curiosity, is there a snfs poly for terms like

a^x+b^x, a != b or
x^y+y^x ?

I'm trying to improve the poly generator but couldnt come up with any.

[QUOTE=Syd;268858]Just out of curiosity, is there a snfs poly for terms like

a^x+b^x, a != b or
x^y+y^x ?[/QUOTE]

They could both be handled as a^x+c with a very large constant term c0 that you would compensate for with a large skew. We need somebody more knowledgeable than me to say whether or not these are likely to be good polynomials.

x "+" c0

.."?"..

[url]http://factordb.com/index.php?id=1100000000442370817[/url]

0..+
`10000000000000000000000000000000000000000000000000063711591624522670185790732155277577204929976855347`*10

..

[url]http://factordb.com/index.php?id=1100000000442371243[/url]

(+2*?)

[QUOTE=Syd;268858]Just out of curiosity, is there a snfs poly for terms like

a^x+b^x, a != b or
x^y+y^x ?

I'm trying to improve the poly generator but couldnt come up with any.[/QUOTE]

Yes. For a^x+b^x, with b < a, if a and b are not coprime take out the common factor, then treat it just like a^x+1. However, rather than X-a^(x/d), the linear poly will be b^(x/d) X - a^(x/d). All the common tricks with x divisible by 3, 5, 7, 11, or 13 work as usual.

For x^y+y^x, see snfspoly.c at [URL="http://tech.groups.yahoo.com/group/xyyxf/files/"]http://tech.groups.yahoo.com/group/xyyxf/files/[/URL].

[QUOTE=frmky;268879]Yes. For a^x+b^x, with b < a, if a and b are not coprime take out the common factor, then treat it just like a^x+1. However, rather than X-a^(x/d), the linear poly will be b^(x/d) X - a^(x/d). All the common tricks with x divisible by 3, 5, 7, 11, or 13 work as usual.

For x^y+y^x, see snfspoly.c at [URL="http://tech.groups.yahoo.com/group/xyyxf/files/"]http://tech.groups.yahoo.com/group/xyyxf/files/[/URL].[/QUOTE]

You can also find several examples of polys for a^x +/- b^x (and a few examples how to calculate them) in the [URL="http://www.mersenneforum.org/showthread.php?t=5722"]homogeneous cunningham numbers thread[/URL].

Thank you, this is exactly what I was looking for!

Note that snfspoly generates degree 5 polynomials: you may want to modify it to generate degree 6 polynomials.

[QUOTE=Syd;268907]Thank you, this is exactly what I was looking for![/QUOTE]One thing: the SNFS polys are missing a "skew" value. You might add something for those that don't know how to set a value....

[QUOTE=schickel;268985]One thing: the SNFS polys are missing a "skew" value. You might add something for those that don't know how to set a value....[/QUOTE]

R.D.Silverman has posted it [URL="http://www.mersenneforum.org/showpost.php?p=266499&postcount=7"]here[/URL] with a hint to read his paper:

[QUOTE]Optimal Parameter Selection for SNFS, J. Math. Cryptology

Computing the skew is easy. No need to guess.

Let the polynomial be a_n x^n + .... + a_0.
Set the skew to (a_0/a_n)^1/n [or its reciprocal depending on how the
code uses it] [/QUOTE]

Just reported my first "List of 1.000 randomly chosen, small composite numbers", mainly 82..84 bits. Over the weekend job with Yafu. Using this opportunity to signal a small bug in yafu, if the batch file has some empty lines inside (empty CR/LF sequences, I edited the downloaded file of "numbers to be factored" with Notepad, to add some other lines in the beginning of it, like [URL="http://www.mersenneforum.org/showpost.php?p=267936&postcount=1"]this one here[/URL], and it got a CR/LF at the end by saving it). In this case yafu goes in an infinite loop saying something like "skipping empty line bla bla bla" and if any numbers to be factored after that line, they will not be reached. When I came to the office this morning, my screen was scrolling up like crazy with that message. Fortunately the log file was clear, the error message is not added into the log, that made my reporting easier, copy/paste.

As a second observation, for some of the numbers I reported, it says "factor already known", so I would be a little skeptical about the "random number generator" that was used, as it seems that some other people got the same numbers like me and factored them over the weekend, faster. From two millions available for factoring, getting random "unique" a thousand should not be too difficult, or maybe there are many-many users working to factor them? (which is not my feeling, I thought there are not so many people full of enthusiasm about finding such "small factors").

[QUOTE=schickel;268739]If you could come up with a quick & easy automated way, I'd say go for it[/QUOTE]

Subscribe 100% to that idea! Waiting for an automated way too.

[QUOTE=LaurV;269113]Just reported my first "List of 1.000 randomly chosen, small composite numbers", mainly 82..84 bits. [/quote]Cool. You've made the FactorDB that much better with your assistance![quote]Over the weekend job with Yafu. Using this opportunity to signal a small bug in yafu, if the batch file has some empty lines inside (empty CR/LF sequences, I edited the downloaded file of "numbers to be factored" with Notepad, to add some other lines in the beginning of it, like [URL="http://www.mersenneforum.org/showpost.php?p=267936&postcount=1"]this one here[/URL], and it got a CR/LF at the end by saving it). In this case yafu goes in an infinite loop saying something like "skipping empty line bla bla bla" and if any numbers to be factored after that line, they will not be reached. When I came to the office this morning, my screen was scrolling up like crazy with that message. Fortunately the log file was clear, the error message is not added into the log, that made my reporting easier, copy/paste.[/quote]You might want to make sure that you report this over in the YAFU [url="http://www.mersenneforum.org/showthread.php?t=10871"]thread[/url] so that bsquared sees the message....[quote]As a second observation, for some of the numbers I reported, it says "factor already known", so I would be a little skeptical about the "random number generator" that was used, as it seems that some other people got the same numbers like me and factored them over the weekend, faster. From two millions available for factoring, getting random "unique" a thousand should not be too difficult, or maybe there are many-many users working to factor them? (which is not my feeling, I thought there are not so many people full of enthusiasm about finding such "small factors").[/QUOTE]That's the main reason I trim out the smaller numbers, so that I'm working, hopefully, a number slightly beyond where any of the automated scripts that work from smaller to larger would be factoring....

Also, you should be aware that >3/4 of the "factor already known" messages are the result of your reporting factors. Here's an example:[quote=FactorDB]Number Factor Result
5346366962...3<96> 111770948692081677297647526622070785956547369<45> Factor added
5346366962...3<96> 4783324311...7<52> Factor already known
5346366962...3<96> 111770948692081677297647526622070785956547369<45> Factor already known
5346366962...3<96> 4783324311...7<52> Factor already known[/quote]For this, I put a number in, then reported the two factors. Notice that the p45 says "Factor added". You see where it says "Factor already known" for the p52? That is because the p52 became "known" [i]when the p45 was divided out of the c96[/i]! Also, for some reasson, the DB lists the reported factors again, but since the p45 is already known, it gets the "factor already known" tag. So for reporting 2 factors, you get one "Factor added" and three "Factor already known" tags. You also get the same effect if there are smaller factors in the mix. When there were a lot of numbers <80 digits, I would get a bunch of factors coming out in the 6-15 digit range, resulting in a 3-way split on the composite. For those, the DB reports "small factor", "factor added", and "factor already known".

So as long as you get a healthy proportion of "Factor added" messages when you do a mass reporting, you know that you are actually helping the matter....

[QUOTE=LaurV;269114]Subscribe 100% to that idea! Waiting for an automated way too.[/QUOTE]I'm not sure if it is totally automated, but if you click the "More information" arrow, then follow the chain "up" the "Is factor of:" links, if the top composite is an SNFS form, there will be an SNFS poly available for download.

[QUOTE=schickel;269116] there will be an SNFS poly available for download.[/QUOTE]

That is a very useful info! I did not know it. Let me see if I can figure out what to do with that poly :D if not, I will come back to you.
For "automated" I understood something like P95, just run it on my wheelbarrow and it would take care by itself of downloading numbers, factoring them (running the tool I tell to it - yafu, else - or eventually factoring algorithm included), report the results.

[QUOTE=LaurV;269121]That is a very useful info! I did not know it. Let me see if I can figure out what to do with that poly :D if not, I will come back to you.
For "automated" I understood something like P95, just run it on my wheelbarrow and it would take care by itself of downloading numbers, factoring them (running the tool I tell to it - yafu, else - or eventually factoring algorithm included), report the results.[/QUOTE]Nope, nothing like that has been posted (that I remember....)

There was some discussion about adding larger tools to the scripts included in this thread, but nothing concrete.

One thing you could do is get numbers in the 100+ digit range (up to ~130 or so, depending on your setup) and run manual NFS jobs. For example, on one of my current aliquot sequences, I'm in the linear algebra stage of an NFS job of 130 digits. Total time ~2 days.

If you took numbers in the 110-120 digit range, you could run NFS jobs overnight and upload the results in the morning....in fact, if you look at the composite report, there is bulge in composites in the 97-109 digit range. Start chipping away at numbers on the high side of that range and you wouldn't have to worry about duplicate work.

Hi,

I also wrote a small Perl script which performes SIQS on composites > 70 digits downloaded from factordb and reports the results back. You just need yafu in the directory where the script runs:
[CODE]
#!/bin/perl

use warnings;
use strict;
use LWP::Simple;

while(1){
print "get composites\n";
my $contents = get("http://factorization.ath.cx/listtype.php?t=3&mindig=70&perpage=1&start=0&download=1");
die "Couldn't get list of composites!" unless defined $contents;

my @composites=split(/\s/, $contents);
foreach my $composite (@composites) {
print "Factoring ".length($composite)." digits: $composite\n";
my @results;
open(YAFU, "yafu siqs($composite) |") or die "Couldn't start yafu!";
while (<YAFU>) {
if (/P.*? = (\d+)/) {
push( @results, $1 );
print "$_\n";
}
}
close(YAFU);

print "report factors\n";
if ( scalar(@results) > 0 ) {
my $url="http://factorization.ath.cx/report.php?report=".$composite."%3D2".join('*',@results);
#print "$url\n";
$contents=get($url);
#print $contents;
}else {
print "Error, no result found\n";
sleep(60);
}
}
}
die;
[/CODE]
yoyo

Thanks. It looks ok, with two small exceptions:

1. I am not a big perl fan. (read that like "I have no idea how to use it and being reticent to learn, from personal reasons, not connected to prime or searching for factors")

2. What's with the links? They seems to point to a different web page, that I can not open in my browser. Is that a mirror of factordb, or are you trying to include me in some factoring team, without my knowledge? "you do the work, we take the glory?" :P

[QUOTE=LaurV;269196]Thanks. It looks ok, with two small exceptions:

1. I am not a big perl fan. (read that like "I have no idea how to use it and being reticent to learn, from personal reasons, not connected to prime or searching for factors")[/quote]Well, unless you roll your own, you're kind of stuck with what everyone's posting here....[quote]2. What's with the links? They seems to point to a different web page, that I can not open in my browser. Is that a mirror of factordb, or are you trying to include me in some factoring team, without my knowledge? "you do the work, we take the glory?" :P[/QUOTE]The [noparse]"factorization.ath.cx"[/noparse] form is the original domain that the DB was available under. It does mirror to [noparse]factordb.com[/noparse].

And I don't know about you, but when I tried [url]http://factorization.ath.cx/listtype.php?t=3&mindig=70&perpage=1&start=0&download=1[/url], here is what I got:[quote=factorization.ath.cx]7227652095162032532139324736930860452869099063319483875357304625277498951240945393[/quote]Fundamentally, the listtype page gives you a bare listing of numbers. "t=3" gives you composites (maybe "composite with no known factors"); "mindig=" gives you composites at a specified size (or larger); "perpage=" gives how many you want per page; "start=" gives you an offset from the beginning of the list; "download=1" specifies how you want the numbers formatted ("1" means strip everything).

The link further down ([noparse]http://factorization.ath.cx/report.php?report=".$composite."%3D2".join('*',@results)[/noparse]) is the same as the "report results" page, just seen from the inside of the html code....

If you go back higher in this thread, you can find where Syd defines the various parameters.....maybe some one should compile everything to a simple guide.