mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   FactorDB (https://www.mersenneforum.org/forumdisplay.php?f=94)
-   -   Other Factordb Problems (https://www.mersenneforum.org/showthread.php?t=16849)

wblipp 2012-05-27 15:11

Other Factordb Problems
 
From time to time things happen in the [URL="http://www.factordb.com"]factordb[/URL] that require manual intervention by the administrator, Syd. Syd's busy. This thread is a parking space to note such problems until Syd gets around to fixing them - the individual posts may then be deleted.

There is already a [URL="http://www.mersenneforum.org/showthread.php?t=16842"]thread [/URL]for broken aliquot sequences. This thread is for everything else.

wblipp 2012-05-27 15:13

[URL="http://factorization.ath.cx/index.php?id=1100000000212962539"]4*938!+1[/URL] should have a simple N-1 primality proof. It starts up OK but doesn't finish - looks like it might be overflow.

wblipp 2012-06-01 15:13

This is a factorization that won't stick. If I enter the factor, it shows as fully factored. But if I click the the "factorize" button again, the status returns to C

This [URL="http://factorization.ath.cx/index.php?id=1100000000185668546"]C149[/URL] is divisible by this [URL="http://factorization.ath.cx/index.php?id=1100000000508699341"]P100[/URL]

Ahh - I see that sometimes the status shows as "err" instead of C or FF.

Stargate38 2012-06-02 21:34

That happens to me to, but it also happens to 9539^41-1 itself without the "err" status.

Dubslow 2012-06-02 21:35

[QUOTE=wblipp;300954]This is a factorization that won't stick. If I enter the factor, it shows as fully factored. But if I click the the "factorize" button again, the status returns to C

This [URL="http://factorization.ath.cx/index.php?id=1100000000185668546"]C149[/URL] is divisible by this [URL="http://factorization.ath.cx/index.php?id=1100000000508699341"]P100[/URL]

Ahh - I see that sometimes the status shows as "err" instead of C or FF.[/QUOTE]

Just appeared as U to me, though a few seconds later it reverted to C.

Stargate38 2012-06-12 13:26

Why is it still doing that? I can't get the P100 to stay. Is there a read-only file in there somewhere that keeps the P100 from staying, thus creating the "err" status, or what else would cause that?

wblipp 2012-06-13 20:48

[QUOTE=wblipp;300954]This is a factorization that won't stick. If I enter the factor, it shows as fully factored. But if I click the the "factorize" button again, the status returns to C

This [URL="http://factorization.ath.cx/index.php?id=1100000000185668546"]C149[/URL] is divisible by this [URL="http://factorization.ath.cx/index.php?id=1100000000508699341"]P100[/URL]

Ahh - I see that sometimes the status shows as "err" instead of C or FF.[/QUOTE]

New Symptom! I got this error message once:
[B][COLOR="Red"]
insert into U values(1100000000185668546,"(9539^41-1)/431293525901506",149,3149750496) - Duplicate entry '1100000000185668546' for key 'PRIMARY'[/COLOR][/B]

Batalov 2012-06-13 21:43

There are probably a couple of daemons (e.g. a PRP-tester thread and a add-a-factor thread) negating each other's work - in the guts of the database. I've recently observed the "factored"-"oh no, not factored, and of U status"-"oh yes it is composite"-"factored with U-type factors"-and back to the beginning vicious circles; a.f.a.i.r. that was for the [URL="http://www.mersenneforum.org/showthread.php?p=302072#post302072"]10^99999+y^3+-1[/URL] PRPs that I've looked at (the PRPs are D.Broadhurst's dated back to ~2003). Maybe it will help debugging.

chalsall 2012-06-13 21:44

[QUOTE=wblipp;302212]New Symptom! I got this error message once:
[B][COLOR="Red"]
insert into U values(1100000000185668546,"(9539^41-1)/431293525901506",149,3149750496) - Duplicate entry '1100000000185668546' for key 'PRIMARY'[/COLOR][/B][/QUOTE]

Is the first field meant to be constrained to being unique? This is what this message is telling you -- you have an unique index on this field.

If this isn't what you want, you can drop the index on the field. Then, if you want that field indexed, add it back without the "unique" option. And/or add a compound unique index including some other fields in addition to this one.

Dubslow 2012-06-13 23:41

Yes, it's supposed to be unique. One ID for each number, and an ID should only point to one number.

How much do you know about FDB? (Not to be rude or anything, it's an honest question.)

chalsall 2012-06-13 23:53

[QUOTE=Dubslow;302217]How much do you know about FDB? (Not to be rude or anything, it's an honest question.)[/QUOTE]

Not a thing.

Dubslow 2012-06-14 00:26

[QUOTE=chalsall;302219]Not a thing.[/QUOTE]

Well, it's pretty aptly named. If you enter a number or expression into the [url=http://factordb.com]homepage[/url] (the box next to "Factorize!") then it will search to see if that number is alway in the database or not. If it is, it will display the status, as well as any known factors. The status can be C (composite, no known factors, [url=http://factordb.com/index.php?query=2%5E1061-1]M1061[/url] is an example), CF (composite with [url=http://factordb.com/index.php?query=8*257%5E132-1]some factors known[/url]), FF ([url=http://factordb.com/index.php?query=2%5E547-1]fully factored[/url]), P (prime), [url=http://en.wikipedia.ork/wiki/Probable_prime]PRP[/url] ([url=http://factordb.com/index.php?id=1100000000517619147]probably prime[/url]), or U for unknown. If the number is not in the database, it will (in most cases) add the number and display its status. It will automatically search for small factors after doing a primality or PRP test, if the number is small enough. Anybody can then submit factors (or primality proofs for PRP/U) and increase the knowledge stored in the database for others to see.

The problem wblipp reported is a C149 (composite number of 149 decimal digits) is divisible by a 100 digit factor, but for whatever reason the database entry for the C149 doesn't consistently show the factor, and the status changes if you refresh the page. There are many such numbers that have been reported over the last few months, except the DB's creator and currently only one with access hasn't been on the forum in a while. It appeared that hw did some maintenance about a month ago, fixing the known problems at the time, but as this thread is a testament to, the underlying bug has not been found/fixed.

(PS Though most of the links don't make it clear, each number's page is "normally" access via the number's unique ID, e.g. [url]http://factordb.com/index.php?id=1100000000517645360[/url] is the page for one of the numbers linked above.)

rcv 2012-06-15 11:49

18^219-1 reports: [COLOR=#ff0000][B]Error: Error, left: 480200321922662777[/B][/COLOR]

[URL="http://www.factordb.com/index.php?query=18%5E219-1"]http://www.factordb.com/index.php?query=18^219-1[/URL]

Update: I see the problem is quite pervasive. 2^33+1 reports a similar error as do dozens (perhaps hundreds) of other smallish Cunningham numbers.

Andi47 2012-06-15 20:13

I have written an email to Syd yesterday - he answered me a few hours ago, that he is currently running a check over the database to remove duplicate entries (i.e. looking for numbers which are e.g. both in the "C" and "P" tables), which should hopefully solve the problems.

fivemack 2012-06-15 22:03

I am slightly confused by the database's behaviour when you give it a proposed-factor which doesn't divide the current number.

My aliquot-sequences script gives me a file of relevant-primes,
[code]

433038489227196549751693963
1251684244750586213152279727961348119745232369106274737154088715302864949971077268531684033064677409
69116907341
15017941960664620362736663813
44805068182716094537202962681398217992189398352022533210918708113429713425925481254380745146795156577380177767149
979586771
140451889094081
6312304681099469891660855169281
901523323453158259576796652552637754388539938211616825391626233569487657112080751335341307588107
11677
5594777
8832387870811152451361030471809549
[/code]

which I copy-and-paste into the 'report factors' box; so some of those are factors for the current number and some aren't. I refresh and re-paste the same list into the 'report factors' box; and now I get 'factor already known' even for something like the long 88xx number at the bottom - it seems that the factor is being given a database entry even though it doesn't divide the current number. Which strikes me as odd.

wblipp 2012-06-16 14:42

[QUOTE=fivemack;302382]I refresh and re-paste the same list into the 'report factors' box; and now I get 'factor already known' even for something like the long 88xx number at the bottom - it seems that the factor is being given a database entry even though it doesn't divide the current number. Which strikes me as odd.[/QUOTE]

I believe the message means "Number already in the database." It means the number already has it's own entry in the database. It relates no information about divisibility - neither if it really divides nor, if it does divide, whether that divisibility was previously know.

danaj 2013-09-15 08:38

[URL="http://www.factordb.com/index.php?id=1100000000618509436"]1100000000618509436[/URL] is on the PRP list, but is a composite. Primo rejects it, but I'm not sure how one tells factordb to recheck with a different PRP method.

PFGW 3.7.7 says "... is PRP!" with the default base, but not with bases 3 or 7.

It is a 2-PSP and 2-SPSP, but not 3-PSP, 5-PSP, 3-SPSP, 5-SPSP, Lucas, Strong Lucas, Extra Strong Lucas, or Frobenius-Underwood pseudoprime (which means, no surprise, it fails BPSW).

I did a brief search for factors, but nothing small came up.

danaj 2013-09-16 09:13

I downloaded the PRP list and set pfgw running on it with base 7. There are more than 270 composites in the list and I haven't finished them all. There doesn't seem to be any way to get them off the list on factordb. For instance, [URL="http://www.factordb.com/index.php?id=1100000000556257811"]1100000000556257811[/URL] has the factor 990033713. But when I enter it in the "Report Factors" box, it won't accept it and continues to show the number as a PRP.

sashamkrt 2013-09-16 17:18

[QUOTE=danaj;353041][URL="http://www.factordb.com/index.php?id=1100000000618509436"]1100000000618509436[/URL].[/QUOTE]
It has a factor PRP33=608439379137786983088754882253701

Batalov 2013-09-16 17:34

It is a composite cofactor of 2^6733+2^3367+1 (a.k.a. 2,13466M), and a cofactor of 2^13466+1, so it is easy to see why it is a 2-PRP.

Send a PM to Syd (or an email if factordb.com has it).

wblipp 2013-09-24 21:23

[QUOTE=danaj;353115][URL="http://www.factordb.com/index.php?id=1100000000618509436"]1100000000618509436[/URL]
[URL="http://www.factordb.com/index.php?id=1100000000556257811"]1100000000556257811[/URL][/QUOTE]

These are now fixed, and there is a new option under "Primality" for PRPs that allows you to designate a base to test.

THANKS, Syd!

Jayder 2014-06-07 07:36

[QUOTE=wblipp;300386][URL="http://factorization.ath.cx/index.php?id=1100000000212962539"]4*938!+1[/URL] should have a simple N-1 primality proof. It starts up OK but doesn't finish - looks like it might be overflow.[/QUOTE]
Maybe not worth mentioning, but this seems to still be an issue. Examples: [URL="http://factordb.com/index.php?id=1100000000514217750"][1][/URL] [URL="http://factordb.com/index.php?id=1100000000592144445"][2][/URL] [URL="http://factordb.com/index.php?id=1100000000514218255"][3][/URL] [URL="http://factordb.com/index.php?id=1100000000556896427"][4][/URL] [URL="http://factordb.com/index.php?id=1100000000255316527"][5][/URL] [URL="http://factordb.com/index.php?id=1100000000633764295"][6][/URL]

The helper files seem fine and I can prove it fine myself with pfgw, but I guess the database still has a hard time with lots and lots of factors.

Stargate38 2014-06-13 19:34

I'm having a problem with the Certificates page. It won't keep the "Show Unprocessed Only" Checked:

[URL]http://www.factordb.com/certoverview.php?digits=300&perpage=100&skip=0&pending=on[/URL]

Stargate38 2014-06-14 17:55

I tried adding M67,108,864 (20,201,782 digits), but it said "Error: Limit of about 10,000,000 digits exceeded". If that's true, then why is it possible to add M57885161 (17,425,170 digits) and all other known primes >10[sup]10[sup]7[/sup][/sup]?

Here's links for proof:
[URL]http://www.factordb.com/index.php?query=M57885161[/URL] (Doesn't give Max. digits error), alt link: [URL]http://www.factordb.com/index.php?id=1100000000583604171[/URL]
[URL]http://www.factordb.com/index.php?query=M67108864[/URL] (Gives Max. digits error)
[URL]http://www.factordb.com/index.php?query=M66438561[/URL] (Largest Mersenne number <10[sup]20000000[/sup], still gives error)

wblipp 2014-06-14 21:05

Perhaps Syd recently added a certificate size limitation. I had a recent email from Syd explaining that the recent stall in processing primality certificates was because of some large certificates that took over a week to process.

danaj 2014-06-14 23:52

Over a week, ouch. For a 18689 digit prime, currently the 12th largest on the primes page, I got a time of 63 hours with my single threaded program on 4770K that had 4 other processes running. Primo for the same cert took 6 hours on an idle 3930K given 12 threads. Clearly a 4770K is faster than the i7-2600, but that's pretty long.

I'd recommend upgrading to GMP 6.0.0a, as that had some pretty major speed updates (~1.2x faster) that impact these operations . Tthe above time was not with it.

Another possibility is to split up the verification into steps. E.g. a "--step <n>" option that says just do that step, and a "--structure" option to verify the structure and return the number of steps. It would allow finer granularity and not lock up one process on a very long running task.

Or maybe Syd has already found a different solution, as the status page looks like things are moving along.

chris2be8 2014-06-15 16:00

Perhaps the limit of "about 10,000,000 digits" is actually between 17,425,170 and 20,201,782 digits. Or Syd might have added M48 as a special case.

Chris

Puzzle-Peter 2014-06-15 17:07

I don't think a single huge certificate is a problem. I and others have uploaded the occasional one and though it takes a long time, there was usually one of these and two or three other workers happily processing the small ones.

Last week however, user msc_nbg uploaded hundreds of certificates for numbers with 10,000+ digits. They all differ in a tiny number of digits, so it MIGHT be the steps that the ECPP proof takes as it is created by a row of primes decreasing in size. THIS IS JUST A GUESS! Anyway this would easily clog up the certificate processing and it would be a rather easy thing to generate these certificates after having done a big PRIMO run.

Just my 2 cents and I might be completely wrong.

Mini-Geek 2014-06-15 18:20

[QUOTE=Puzzle-Peter;375901]Last week however, user msc_nbg uploaded hundreds of certificates for numbers with 10,000+ digits. They all differ in a tiny number of digits, so it MIGHT be the steps that the ECPP proof takes as it is created by a row of primes decreasing in size. THIS IS JUST A GUESS! Anyway this would easily clog up the certificate processing and it would be a rather easy thing to generate these certificates after having done a big PRIMO run.

Just my 2 cents and I might be completely wrong.[/QUOTE]

Maybe the person's thinking was, "My ECPP proof has this chain of things that are all proved prime (even though only the first was noteworthy enough to want to prove). I should tell the DB about all of them!".
Maybe the DB should (if it doesn't already) look at the certificate, and add all of the primes proved in this chain to the DB. This would also mean that it doesn't have to reprocess a certificate chain over and over. (this could be done regardless of if your guess here is right, and that's what happened here)

Puzzle-Peter 2014-06-16 09:46

[QUOTE=Mini-Geek;375906]Maybe the person's thinking was, "My ECPP proof has this chain of things that are all proved prime (even though only the first was noteworthy enough to want to prove). I should tell the DB about all of them!".
Maybe the DB should (if it doesn't already) look at the certificate, and add all of the primes proved in this chain to the DB. This would also mean that it doesn't have to reprocess a certificate chain over and over. (this could be done regardless of if your guess here is right, and that's what happened here)[/QUOTE]

After one of my first PRIMO certificates I did wonder about that myself. I was simply too lazy to take action. Plus - as others pointed out - the probability of "recycling" one of those primes is just about zero so I didn't bother.

Still they are proven primes and why not store them in FactorDB. I think extracting them from the certificates is a good idea and shouldn't be too hard to do.

wblipp 2014-06-16 16:13

[QUOTE=Puzzle-Peter;375947]the probability of "recycling" one of those primes is just about zero[/QUOTE]

I still find this argument compelling. It might be possible to convince me to support a database modification that stored the one certificate and tagged all the primes as proven by that one certificate. But I oppose the successive shortening of the certificate and resubmission after each shortening as a waste of resources - both computing and storage resources. I doubt Syd has the time to make such a database modification.

danaj 2014-06-17 01:21

It's come up before, and I wrote a simple Perl program to create new verifiable certs just to make sure it could be practically done. But I think it's a really bad idea. If desired, this is something the database should efficiently store (just a note that the proof for number N is step 45 of entry XXXXX), and generate the small cert from the larger one if requested.

Stargate38 2014-06-17 16:00

I think I found the DB's max value. It's somewhere between M62000000 and M62000001, but I was able to get M62000001 by typing in "2*M62000000+1".

Jayder 2014-06-18 22:31

This is exasperating. msc_ngb added [URL="http://factordb.com/index.php?id=1100000000662402799"]this[/URL] 16,386 digit prime and then added [B][U]all 1900 steps[/U][/B]. About 160 are above 15,000 digits, 540 between 10-15k digits, and about 540 between 5-10k digits. There are 1354 certificates in the queue right now, and the vast majority of them are just these "steps". I feel like this is a humongous waste of resources.

Jayder 2014-06-19 15:21

[QUOTE=Jayder;376167]I feel like this is a humongous waste of resources.[/QUOTE]
It looks like this may have been rectified, at least for the moment. msc_nbg's total certificates dropped by about 30k, and the queue is now clear. Looks like they were all deleted. Thanks Syd(?)! Hope this lasts.

RichD 2014-06-21 23:25

As info
 
[QUOTE=Jayder;375275]Maybe not worth mentioning, but this seems to still be an issue. Examples: [URL="http://factordb.com/index.php?id=1100000000514217750"][1][/URL] [URL="http://factordb.com/index.php?id=1100000000592144445"][2][/URL] [URL="http://factordb.com/index.php?id=1100000000514218255"][3][/URL] [URL="http://factordb.com/index.php?id=1100000000556896427"][4][/URL] [URL="http://factordb.com/index.php?id=1100000000255316527"][5][/URL] [URL="http://factordb.com/index.php?id=1100000000633764295"][6][/URL]

The helper files seem fine and I can prove it fine myself with pfgw, but I guess the database still has a hard time with lots and lots of factors.[/QUOTE]

Even with the latest enhancements and checks-and-balances, these are still an issue.

RichD 2014-06-25 20:48

[QUOTE=wblipp;375964]I still find this argument compelling. It might be possible to convince me to support a database modification that stored the one certificate and tagged all the primes as proven by that one certificate.[/QUOTE]

I agree. If someone would request the certificate of one of the steps (primes) tagged, then the database could easily build the cert from the remaining steps.

Then again, if Syd only had the time. :smile:

RichD 2014-07-03 14:30

[QUOTE=Jayder;375275]... but this seems to still be an issue. Examples: [URL="http://factordb.com/index.php?id=1100000000514217750"][1][/URL] [URL="http://factordb.com/index.php?id=1100000000592144445"][2][/URL] [URL="http://factordb.com/index.php?id=1100000000514218255"][3][/URL] [URL="http://factordb.com/index.php?id=1100000000556896427"][4][/URL] [URL="http://factordb.com/index.php?id=1100000000255316527"][5][/URL] [URL="http://factordb.com/index.php?id=1100000000633764295"][6][/URL][/QUOTE]

The Proof button now works for the above six. All are proven prime via N-1.

richs 2014-07-18 14:54

This number is broken (see the last factor):

[URL="http://www.factordb.com/index.php?id=1100000000305397690"]http://www.factordb.com/index.php?id=1100000000305397690[/URL]

chris2be8 2014-07-18 16:09

It looks OK to me. The last divisor is a p110 raised to power 33. Which look a bit odd the first time you see it but is OK.

The next question is how long it will be until someone factors the next-to-last-factor C92.

Chris

wblipp 2014-07-18 16:12

[QUOTE=richs;378461]This number is broken (see the last factor):

[URL="http://www.factordb.com/index.php?id=1100000000305397690"]http://www.factordb.com/index.php?id=1100000000305397690[/URL][/QUOTE]

Perhaps this has been fixed. As of my writing, the factordb shows the last factor as a 110 digit prime raised to the 33rd power. [URL="http://www.alpertron.com.ar/ECM.HTM"]Alpertron[/URL] agrees that factorization.

richs 2014-07-18 23:37

It must have been a glitch. I was factoring the C92 at the time and I like to look at the entire number.

chris2be8 2014-08-17 16:15

The list of smallest numbers without known factors contains the following 3 entries: [code]
1100000000704879936 0 1
1100000000704879961 0 1
1100000000704879980 0 1
[/code]
Clicking on the 0 shows they are all 7##-7##.

I think this needs SYD to intervene.

Chris

Batalov 2014-08-17 16:56

The ## parsing [URL="http://mersenneforum.org/showthread.php?t=19443"]has been broken[/URL] in FactorDB for a while and is till broken.

chris2be8 2014-09-02 17:19

The status page shows 1 primality certificate is processing (for id 1100000000684205656). But when I look at it the certificate was uploaded on 21 August. So somethings wrong.

Can anyone except Syd do anything about this?

Chris

danaj 2014-09-04 16:40

[QUOTE=chris2be8;381946]The status page shows 1 primality certificate is processing (for id 1100000000684205656). But when I look at it the certificate was uploaded on 21 August. So somethings wrong.[/QUOTE]If I had the cert I could at least check if the verifier has problems. I ran Primo on that input and the verifier is fine with my certificate and finishes in under 2 minutes, but it almost certainly is not identical to the one that was submitted.

chris2be8 2014-09-05 15:54

Unfortunately factordb won't let you download a certificate that is being processed. I tried to get round it by copying the link to download another certificate and changing the ID in it, but that didn't work.

So unless RobertS has a copy of the certificate he uploaded we are stuck.

Chris

Batalov 2014-09-17 17:09

[url]http://factordb.com/index.php?id=1100000000626093581[/url] has a tag "CF"
(but it isn't).
Its child [url]http://factordb.com/index.php?id=1100000000626093582[/url] has status "err".

Markus, if you could please drop one or the other record, to fix this?

This is a member of the 270870 sequence which gets stuck on this number; but the shadow sequence goes beyond as can be seen by [URL="http://factordb.com/sequences.php?se=1&aq=129111051894876298008618452174572111386084321838395106159352526283699001422613851356969918762669577402931599473069044&action=last20&fr=0&to=100"]following its tail[/URL]

LaurV 2014-09-18 14:39

Same story for 711606.

ChristianB 2014-12-04 10:56

2 of my recently uploaded primo certificates are stuck. I don't have those certs anymore but I can recreate them. Did anyone try to reupload a certificate in order to unstuck the verifier? What else can I do?

Stargate38 2014-12-04 19:32

About [URL]http://factordb.com/index.php?id=1100000000626093582[/URL] and its err status, [URL]http://factordb.com/index.php?id=1100000000734146738[/URL] (10*[URL]http://factordb.com/index.php?id=1100000000626093582[/URL]) has no problem. The problem with 711606 seems to be fixed.

storflyt32 2014-12-17 12:53

Should I still try giving you a hand solving these problems?

Found another bug which affects handling of things a little bit.

There was a problem here with regards to system hang and slowness.

Apparently it become a little better again yesterday.

I experienced a problem when switching between Notepad, Yafu and Google Chrome.

Each time Chrome had to be minimized in order for me to return back to the other two applications.

There is still a problem when it comes to task switching. For some reason, Windows prefers returning to the desktop when using ALT-TAB or SHIFT-ALT-TAB for this.

Possibly the Windows Task Manager has become garbled when it comes to its icon setup on the desktop.
At least it does not always come up (or may even have become stuck and needs to be clicked in order to be restored.

In fact I find it to be slow at times. It really should have high priority when it comes to the running.

The most important problem is the display of the current number on the page when in the Factor Database.

When the number is not listed by means of a syntax, you have it readily available.

But when using Google Chrome and Yafu, I have the latter in a window boxed (a "restored" window, but not maximized.

Full screen does not work for DOS here.

So I need to copy a number from Yafu one line at a time if I do not have the time at making a copy of it into Notepad first, giving me a total entry.

I press F5 in order to update the web-page to be sure that I get the correct number for the active page.

But giving in a new number one line at a time from Yafu, what is supposed to be the number line in the Factor Database is not selected as active.

Either I am at the start of the line, or possibly in between there somewhere.

Again using Google Chrome for this.

Each time a number needs to be filled in, I have to click on the number field (which "again" is supposed to be for the output presentation) with the mouse and press END in order to get to the end (the end of the number) and continue filling in there.

That is when the number is more than is visible at one time in the box which happens at times.

I am not logged in when using this, just being anonymous.

But two lines, one for input and one for output could have worked better for this when it comes to the Factor Database, in my opinion.

Stargate38 2015-02-22 18:16

DB taking forever to post factors
 
Why is the db suddenly running so slow? I tried to post the algebraic factor 136412617295242272621137241954094939075362960769851163951801668863505821547168 of [URL]http://www.factordb.com/index.php?id=1100000000757517735[/URL] and it took 159.76 seconds.

chris2be8 2015-02-23 16:57

I've noticed it is very slow too. On the status page the system load is often very high (it's about 20 now) which suggests it's being overloaded. It could be someone is adding loads of numbers to it.

Chris

Hailstone 2015-02-24 10:36

I've been uploading a bunch of numbers to the database. I was trying to add more today, but I've been getting a "Could not connect to database" error. Does anyone know what's going on?

rodac 2015-02-24 15:18

I have the same problem: "Could not connect to database".

ugly2dog 2015-02-24 16:43

I was having the same issue, finally got in and it is showing a system load of
Load average, last minute 482.97
Load average, last 5 minutes 405.7
Load average, last 15 minutes 309.55
Someone is hammering the hell out of the db.

It has been busy at about the same time of day for the past week or so, but it has gotten steadily worse each day.

BudgieJane 2015-02-24 17:50

It's back to "Could not connect to database" again.

Stargate38 2015-02-24 20:22

I'm guessing it's cmd again (I'm getting the same error), but it could be anyone.

yoyo 2015-02-24 21:04

Syd is working on the issue.

Syd 2015-02-24 21:35

Hi everyone,

the server was unresponsive again, even ssh timed out. But there were almost no log entries - my guess is its some kind of hardware problem.

I´ll run some checks now, this might take till tomorrow.

-Syd

Syd 2015-02-25 00:36

All tests finished, no hardware problems. I created another backup and put the site back online.

RichD 2015-02-25 06:36

Probably memory leaks.

It has been running for a long, long time.

Great work!

Syd 2015-02-25 14:39

Thanks.

I already restarted it a few days before. My guess its the SSD - its at 100% load with only 10kb/s write load. With >5TB total written its not unlikely its going to fail soon.

I´ll replace it when I get to the server next week.


[QUOTE=RichD;396296]Probably memory leaks.

It has been running for a long, long time.

Great work![/QUOTE]

chris2be8 2015-02-28 09:07

Factordb is slow again. Queries seem OK, but updates such as adding a factor are very slow.

Chris

ChristianB 2015-03-04 10:56

The certificate for this [url=http://factordb.com/index.php?id=1100000000759078678]PRP452[/url] is stuck (it's not mine)

Dubslow 2015-04-23 02:19

Is there a reason that the "show digits" page has a line break after every 120 digits?

view-source:[url]http://factordb.com/index.php?showid=1100000000744999917[/url]

Let the browser take care of wrapping please. That makes it difficult or impossible to either copy to clipboard or parse.

Batalov 2015-04-23 02:34

That's true.

I can also add a constructive solution. Borrow the solution from Kamada: he inserts soft break symbols after each 10 or 20 digits, so that browser arranges long, very long and even very-very-very long lines quite fine and this doesn't interfere with copy pasting!

Example: [url]http://stdkmd.com/nrr/repunit/tm.cgi?p=20[/url]
Here is the snippet of the HTML code (remove spaces in [COLOR="Red"]­& shy;[/COLOR])
[CODE]...
·
4404410875574787768521718346256386184129[COLOR="Red"]& shy;[/COLOR]4905937408483757953142563366126920380374[COLOR="red"]& shy;[/COLOR]1415744566525108430933975383194546209<sub>&lt;117&gt;</sub>
·
...[/CODE]

WraithX 2015-04-23 03:06

[QUOTE=Batalov;400673]That's true.

I can also add a constructive solution. Borrow the solution from Kamada: he inserts soft break symbols after each 10 or 20 digits, so that browser arranges long, very long and even very-very-very long lines quite fine and this doesn't interfere with copy pasting!

Example: [url]http://stdkmd.com/nrr/repunit/tm.cgi?p=20[/url]
Here is the snippet of the HTML code (remove spaces in [COLOR="Red"]­& shy;[/COLOR])
[CODE]...
·
4404410875574787768521718346256386184129[COLOR="Red"]& shy;[/COLOR]4905937408483757953142563366126920380374[COLOR="red"]& shy;[/COLOR]1415744566525108430933975383194546209<sub>&lt;117&gt;</sub>
·
...[/CODE][/QUOTE]

Except on my computer, using Firefox, that "shy;" apparently gets rendered as a hyphen character during word-wrap. I see word-wrapped numbers having a hyphen in the middle, and the copy-paste shows it too:
[CODE]
(number with no word wrap [and no hyphen] in the mersenneforum compose window, ie: all "& shy;" removed)
411787862686527277778189093087440420830553838594950372431901923887375670137663697709143850343503541936143792859596510698­48809053<128>

(number with a single word wrap [and a single visible hyphen] in the mersenneforum compose window, ie: all "& shy;" in place)
4117878626865272777781890930874404208305­5383859495037243190192388737567013766369­7709143850343503541936143792859596510698­48809053<128>

(html of number from Kamada's page)
· 4117878626865272777781890930874404208305& shy;5383859495037243190192388737567013766369& shy;7709143850343503541936143792859596510698& shy;48809053<sub>&lt;128&gt;</sub> ·[/CODE]

And... strange, a single hyphen shows up in the mersenneforum text-box compose-message window (at the word-wrap point), but it does not show up in the message that is rendered/posted to the forum. Also, each "& shy;" is rendered as a hyphen when I copy-paste into my text editor. This solution doesn't seem to work on my system. :no:

Batalov 2015-04-23 20:31

Yeah, indeed, it is not perfect either. I remembered that it worked (I think) on his old site.
He also has some hidden java code that can compute the very long values which are initially hidden for brevity but expand if you click on them; there are some interesting ideas in the design of his site.

chris2be8 2015-04-28 15:38

The site has been down for over an hour. [code]
ping factordb.com
PING factordb.com (176.9.39.214) 56(84) bytes of data.

--- factordb.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5010ms


linux-5hwg:~ # traceroute factordb.com
<snip>
12 juniper2.rz15.hetzner.de (213.239.245.198) 54.798 ms * juniper1.rz15.hetzner.de (213.239.245.202) 54.163 ms
13 hos-tr4.ex3k5.rz15.hetzner.de (213.239.244.102) 55.626 ms hos-tr1.ex3k5.rz15.hetzner.de (213.239.244.6) 55.230 ms hos-tr3.ex3k5.rz15.hetzner.de (213.239.244.70) 60.146 ms
14 * * allprojectstats.com (176.9.39.214) 54.008 ms
[/code]
Chris

Dubslow 2015-04-28 15:50

It's up for me, and my scripts (different location/ISP than me currently) haven't reported any problems.

[url]http://downforeveryoneorjustme.com/factordb.com[/url] <-- also seems to be up from them

chris2be8 2015-04-28 15:57

It came back up shortly after I posted. It was certainly down though.

Chris

Dubslow 2015-04-28 17:20

[QUOTE=chris2be8;401110]It came back up shortly after I posted. It was certainly down though.

Chris[/QUOTE]

My script runs every half hour and didn't report anything amiss

rob147147 2015-04-28 17:53

It was just intermittent timeouts for some reason. I'd just cleared everything up to C92's, and happened to be watching when someone dumped about 2,000 small composites C65-C75 in the database and my workers struggled to grab them from the server.

chris2be8 2015-04-29 16:42

Taking another look at the traceroutes I ran it was probably a network issue affecting the last few hops before factordb.com. So it may not have affected people connecting from different parts of the world.

Chris

axn 2015-05-13 08:05

2^490*490##+1 aka 3511#*2^490+1 ([url]http://www.factordb.com/index.php?id=1100000000777746256[/url])

I do N-1 proof, and apparently PFGW's definition of ## is different from factordb's, so it is tagged as composite.

EDIT:- [url]http://www.factordb.com/index.php?id=1100000000777751427[/url] (2^524*524##-1)

Batalov 2015-05-13 16:47

[QUOTE=axn;402231]...and apparently PFGW's definition of ## is different from factordb's, so it is tagged as composite.
[/QUOTE]
## in FactorDB seems to be known to be incorrect (and of course, any larger number of ##...#s, by extension)
Point in case: 4# is correctly parsed as 6, but then, why is 4## = 210 in FactorDB??

Wick 2015-05-13 18:49

According to the help:

# Primordial (product of all primes below n, postfix)
## Product first n primes (postfix)

4# = 6
4## = 210 (2*3*5*7)
(4#)# = 30

seems correct?

Batalov 2015-05-13 19:23

1) That's a very "intuitive" design. If you can show how to get this helpful "help"? [SPOILER]except as deduced by this comment that it actually exists, and if so, then it just might be at factordb.com/help ... and in fact this page [B]does[/B] exist, in its own world - not linked to any other pages.[/SPOILER]
2) nobody uses this notation
3) what is 4### then? and why? and what is 4#### -- is it (4##)## ? (((4#)#)#)# ? ((4#)#)## ? ((4##)#)# ?

axn 2015-05-14 03:23

FWIW, I just put n## in the search box and looked at the series that factordb printed out. :smile:

Of course, the problem is that PFGW interprets ## the same way it inteprets !! (multifactorials), i.e. product of every other prime.
[QUOTE]What we've got here is failure to communicate[/QUOTE]

Batalov 2015-05-14 03:48

Yes, the PFGW way makes sense. Using ## for something that cannot be written (easily) in another way makes more sense.
Like the motto of a certain method, “To [I]make[/I] the [I]impossible possible[/I], the [I]possible easy[/I], and the [I]easy[/I] elegant.”

Using n## for p[SUB]n[/SUB]# doesn't make impossible possible, or even possible much easier than it is. If 4## is simply 7# and 10## is simply 29#, then what's the economy?

axn 2015-05-14 04:39

[QUOTE=Batalov;402274]Using n## for p[SUB]n[/SUB]# doesn't make impossible possible, or even possible much easier than it is.[/QUOTE]

Not when we're looking at an individual number, no. But, it does help when looking at series. For example, I believe the two numbers I posted came out of series n##*2^n+/-1.

Anywho... whatever format it internally supports, it needs to standardise that when communicating with external tools (like PFGW).

PS:- From factordb.com home page, if you click on the [B]?[/B] link to the right, you'll get the help link. It has page=0 parameter. There are apparently help pages available for 1 & 2 as well :smile:

Batalov 2015-05-14 06:32

True!

I saw a similar conceptual disconnect at UTM, but in a rare category. I submitted a partition number and all old submissions were in "p(n)" form. But for PFGW, p(n) is the prime number #n, so for a brief moment the prime was deleted (for being too small), then restored again manually by CC.

So, anyway, FactorDB's 10## could be represented as p(10)# in PFGW (and could as well be the same in factorDB, if a prefix function p(n) is implemented).

Let's see. PFGW has these built in: p(n), Phi(n,x), gcd(x,y), F(n), L(n), and also U(n), V(n) (primitive parts of F(n), L(n)); doesn't have numbpart(), or bernfrac(), or some other things, -- for them one can use a bridge from GP to PFGW. FactorDB has only a subset of these.

Antonio 2015-05-14 06:42

[QUOTE=Wick;402249]According to the help:

# Primordial (product of all primes below n, postfix)
## Product first n primes (postfix)

4# = 6
4## = 210 (2*3*5*7)
(4#)# = 30

seems correct?[/QUOTE]

Factordb is still inconsistent even with it's own definition.
Consider it's solution to 5# [SPOILER] =2*3*5 =30[/SPOILER], which should be the same as 4# according to it's definition..

Wick 2015-05-14 07:53

[QUOTE=Batalov;402250]1) That's a very "intuitive" design. If you can show how to get this helpful "help"? [SPOILER]except as deduced by this comment that it actually exists, and if so, then it just might be at factordb.com/help ... and in fact this page [B]does[/B] exist, in its own world - not linked to any other pages.[/SPOILER]
2) nobody uses this notation
3) what is 4### then? and why? and what is 4#### -- is it (4##)## ? (((4#)#)#)# ? ((4#)#)## ? ((4##)#)# ?[/QUOTE]

next to the factorize button on every page there is a ?. If you click it you go here: [URL]http://www.factordb.com/help.php?page=0[/URL]

chris2be8 2015-05-27 15:50

Factordb seems unreasonably slow processing primorials. Eg the following two PRPs should be easy to prove prime by N-1 but clicking on Primality gets a LONG wait then an incomplete page as if the attempt to calculate how far factored N-1 is timed out.

26901*115637#+1
27545*115637#+1

Chris

Stargate38 2015-08-03 19:04

What's causing the "err" status on certain numbers? It's breaking 9 of the Aliquot sequences. Here's an example (from 270870):

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

schickel 2015-08-04 01:17

[QUOTE=Stargate38;407182]What's causing the "err" status on certain numbers? It's breaking 9 of the Aliquot sequences. Here's an example (from 270870):

[url]http://factordb.com/index.php?id=1100000000626093582[/url][/QUOTE]i think for all the sequences that are broken they are broken as a result of errors like this. If you look, the number is even, but something bombed when the number was inserted and it will not accept factors reported (or anything else). They're a matter for Syd to fix, unfortunately.

chris2be8 2015-09-03 16:56

After clicking Combined N-1/N+1-test for (1205^311-1)/1204, [url]http://factorization.ath.cx/index.php?id=1100000000802222052[/url], I got: [code]
Test finished!
PFGW output:

Primality testing (1205^311-1)/1204 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 2
Running N+1 test using discriminant 11, base 2+sqrt(11)
Calling N-1 BLS with factored part 32.16% and helper 3.06% (99.56% proof) Proof incomplete rerun with -x31906
(1205^311-1)/1204 is Fermat and Lucas PRP! (0.1456s+0.0001s)
[/code] But it still shows as composite.

N-1 shows 32.177% factored and N+1 shows 3.088% factored so it should be able to prove it prime.

Chris

paulunderwood 2015-09-03 18:58

What are the contents of the "helper" file? :smile:

axn 2015-09-04 02:42

[QUOTE=chris2be8;409504]N-1 shows 32.177% factored and N+1 shows 3.088% factored so it should be able to prove it prime.
Chris[/QUOTE]

32.177*3+3.088 = 99.619 is short of 100% needed for the proof. You need another 956 * (100.-99.619)% = 4 digits more of factors
EDIT:- Actually it says right there what needs to be done.
[QUOTE]Calling N-1 BLS with factored part 32.16% and helper 3.06% (99.56% proof) Proof incomplete rerun with -x31906[/QUOTE]

chris2be8 2015-09-04 16:08

[QUOTE=paulunderwood;409515]What are the contents of the "helper" file? :smile:[/QUOTE]

[code]
2
3
5
11
31
41
67
241
311
373
1117
5333
19841
65581
94201
14454014741
15310978493
51466530341
238577955233
3623008528351
16882076013511
571942065602617231
136579192917993601851013
304886788909843277271659233981
24093066218972488602853684540493150881377214116399041593
2707569731064359648574014702758332334432814852672149601505089496049710691427
23
23008944777617
144698299486159
[/code]
But does that help?

Chris

chris2be8 2015-09-04 16:18

[QUOTE=axn;409549]32.177*3+3.088 = 99.619 is short of 100% needed for the proof. You need another 956 * (100.-99.619)% = 4 digits more of factors
EDIT:- Actually it says right there what needs to be done.[/QUOTE]

When I first saw the number I ran some ECM against the composite factors of N-1 and N+1. And found a small factor of N+1. But that's probably used up my quota of luck.

The interesting point is that factordb provides a proof button, even thought there aren't quite enough known factors to prove the number prime.

Chris

paulunderwood 2015-09-04 16:24

[CODE]./pfgw64 -V -i -tc -q"(1205^311-1)/1204" -hahelper.txt -x31906
PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11]


CPU Information (From Woltman v26 library code)
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
CPU speed: 3257.16 MHz, 4 cores
CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2, SSE4.1, SSE4.2
L1 cache size: 32 KB
L2 cache size: 256 KB, L3 cache size: 8 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes
TLBS: 64

Primality testing (1205^311-1)/1204 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Reading factors from helper file ahelper.txt
Running N-1 test using base 2
Generic modular reduction using generic reduction AVX FFT length 320 on A 3173-bit number
Running N+1 test using discriminant 11, base 2+sqrt(11)
Generic modular reduction using generic reduction AVX FFT length 320 on A 3173-bit number
(1205^311-1)/1204 is prime! (0.1615s+0.0005s)
[/CODE]

[QUOTE] -x Additional Square Free Testing
This will make PFGW try to prove a prime with a tiny bit less then
33.3% factorisation of N-1 or N+1.
Default value is -x100
[/QUOTE]

axn 2015-09-04 16:43

[QUOTE=chris2be8;409596]The interesting point is that factordb provides a proof button, even thought there aren't quite enough known factors to prove the number prime.[/QUOTE]

Yes. Factordb (incorrectly) calculates it as 3*(m+p) instead of 3*larger(m,p)+smaller(m,p).

jyb 2015-09-23 18:04

Is anybody able to use factordb.com at all right now? It does nothing but show me the "maximum parallel requests" page, even trying to load its home page.

Does it need a kick?


All times are UTC. The time now is 09:41.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.