Factoring database

[schickel]

Originally Posted by maxal

factordb may return incomplete factorization of a proper factor of a completely factored number.

E.g., for 10^486 - 1 it returns complete factorization (FF status), while for (10^486-1)/487 it returns incomplete factorization (CF status).

Is it a bug or feature?

Actually, this has come up before. When you enter an expression in the search box, it is parsed to come up with a value to query. Since the two expressions crunch to different values, the DB starts from two different IDs. If you feed the factors from the first result to the second result, it will figure out that the second one is FF also......

[maxal]

Originally Posted by schickel

If you feed the factors from the first result to the second result, it will figure out that the second one is FF also......

It would be nice if the engine was able to figure that out automatically. If I use it for factoring, I do not want to care about relationship of the input number to other numbers in the database, I just want to pull up from the database as many factors as possible.

[VolMike]

Is that possible to get all known factors of the choosen number in a plain text form by http request?

[wblipp]

Originally Posted by VolMike

Is that possible to get all known factors of the choosen number in a plain text form by http request?

Here it is for (10^486-1)/487

Use the factor tables page displaying only one number in text form.

[VolMike]

Originally Posted by wblipp

Here it is for (10^486-1)/487

Use the factor tables page displaying only one number in text form.

Thanks! Quite interesting way to get the factorization.

[bchaffin]

The aliquot sequence for 174888 seems to be broken... it appears that sigma was computed incorrectly at term 143.

[LaurV]

Originally Posted by bchaffin

The aliquot sequence for 174888 seems to be broken... it appears that sigma was computed incorrectly at term 143.

That is right, term 143 is 8171995960632149250568 but is displayed by the DB as 8171995856272822285048. This is quite a "new" mistake of the DB (happened in the last days, and looks like a disk corruption). I am sure that I worked this sequence in the past, higher then 100 digits! In fact many other people checked all the sequences with small terms, pushing them over 100, there was no sequence under 100 digits.

This is a totally "new" branch of 174888, which branch never went over 100 digits, it is a "new" acquisition, maybe a mistake happened on the server in the last days, and the DB elves just worked it on to 75 digits. If it should be older, then it should be worked higher. As additional proof, filling 8171995960632149250568 as a start for a sequence, it goes to 116 digits, with 2^3*3*5 (that is "my" driver! :P)

[schickel]

Originally Posted by bchaffin

The aliquot sequence for 174888 seems to be broken... it appears that sigma was computed incorrectly at term 143.

Originally Posted by LaurV

That is right, term 143 is 8171995960632149250568 but is displayed by the DB as 8171995856272822285048. This is quite a "new" mistake of the DB (happened in the last days, and looks like a disk corruption).

I last downloaded 174888 on 2/2 (or was it 2/2?) and it's bad from then.

The problem is this line:

 142 .   8734000210977209181752 = 2^3 * 37 * 193 * 152884753728070459

The DB shows this number as FF, but then shows it as a p19. It should actually be:

152884753728070459 = 207715517 x 736029527

Looks like someone hit the "Set Prime" button again!

[smh]

Back from vacation i tried to upload some aliquot sequences. But already on the first upload:

You have reached your hourly limit of 3000 IDs created.

[schickel]

Originally Posted by smh

Back from vacation i tried to upload some aliquot sequences. But already on the first upload:

Any chance that you're behind a proxy that might be shared by other DB users?

The 3000 limit is for a non-logged in users and it appears to be tracked by IP.

I wonder how widely spread the users of the DB are.....

[schickel]

Originally Posted by schickel

I last downloaded 174888 on 2/2 (or was it 2/2?) and it's bad from then.

The problem is this line:

 142 .   8734000210977209181752 = 2^3 * 37 * 193 * 152884753728070459

The DB shows this number as FF, but then shows it as a p19. It should actually be:

152884753728070459 = 207715517 x 736029527

Looks like someone hit the "Set Prime" button again!

OK, now the line is being displayed properly, but the sequence is still messed up a little. The number for line 143 is still being displayed wrong, and it goes up to 1470+ lines that are still wrong, but wrong in a different way than we just had.

@Syd, can you force the DB to reclaculate 174888? Maybe it can be reconstructed....