Other Factordb Problems

[Dubslow]

Originally Posted by chalsall

Not a thing.

Well, it's pretty aptly named. If you enter a number or expression into the homepage (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, M1061 is an example), CF (composite with some factors known), FF (fully factored), P (prime), PRP (probably prime), 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. http://factordb.com/index.php?id=1100000000517645360 is the page for one of the numbers linked above.)

[rcv]

18^219-1 reports: Error: Error, left: 480200321922662777

http://www.factordb.com/index.php?query=18^219-1

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]

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]

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,

433038489227196549751693963
1251684244750586213152279727961348119745232369106274737154088715302864949971077268531684033064677409
69116907341
15017941960664620362736663813
44805068182716094537202962681398217992189398352022533210918708113429713425925481254380745146795156577380177767149
979586771
140451889094081
6312304681099469891660855169281
901523323453158259576796652552637754388539938211616825391626233569487657112080751335341307588107
11677
5594777
8832387870811152451361030471809549

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]

Originally Posted by fivemack

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.

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]

1100000000618509436 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]

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, 1100000000556257811 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]

Originally Posted by danaj

1100000000618509436.

It has a factor PRP33=608439379137786983088754882253701

[Batalov]

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]

Originally Posted by danaj

1100000000618509436
1100000000556257811

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]

Originally Posted by wblipp

4*938!+1 should have a simple N-1 primality proof. It starts up OK but doesn't finish - looks like it might be overflow.

Maybe not worth mentioning, but this seems to still be an issue. Examples: [1] [2] [3] [4] [5] [6]

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.