-   FactorDB (
-   -   Other Factordb Problems (

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=]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=]M1061[/url] is an example), CF (composite with [url=*257%5E132-1]some factors known[/url]), FF ([url=]fully factored[/url]), P (prime), [url=http://en.wikipedia.ork/wiki/Probable_prime]PRP[/url] ([url=]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][/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]


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,


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=""]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=""]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

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 has it).

wblipp 2013-09-24 21:23


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


Jayder 2014-06-07 07:36

[QUOTE=wblipp;300386][URL=""]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=""][1][/URL] [URL=""][2][/URL] [URL=""][3][/URL] [URL=""][4][/URL] [URL=""][5][/URL] [URL=""][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.

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

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