Factoring database

[RichD]

Found several more.

On the 96 composite page(s) there are:
1210011
1210017
1210002
1210003

On the 97 page(s):
1210005
1210000
1210010
1210013

Note: They may not appear on the first page of each size.

[schickel]

Originally Posted by RichD

Hmm, I didn't notice any change (still indicates a C). The numbers in question I was looking at were 1210016 & 1210012.

The anomaly is only noticeable from the list of 95 digit composites.

1210012 was the one I saw, and to make it even weirder, if you search this way, 1210012 shows up as "FF" which is what I saw. It looks like the expression parser is thrown off by the "%" in the expression.....have you tried any other expressions with a "%" in them?

[RichD]

Originally Posted by schickel

It looks like the expression parser is thrown off by the "%" in the expression.....have you tried any other expressions with a "%" in them?

I didn't introduce the "%", I just noticed it when I inquired why a c7 was in the list of c95s.

[schickel]

Originally Posted by RichD

I didn't introduce the "%", I just noticed it when I inquired why a c7 was in the list of c95s.

I realize that; I saw it the same way. I was wondering if you had experimented with other expressions with a "%" in them....it would be interesting to see where the "%" figures in the hierarchy of symbols while parsing expressions.

[xilman]

Originally Posted by schickel

Sorry, that was me exploring a little bit. I think you'll find your issue is related to this discussion:Basically, if you report a factorization of a number by using "report factors" this way:

x = a * b * c * d

the DB ends up knowing that a, b, c, & d are factors of x, but it doesn't know the other combinations like

ab = a * b
abc = a * b * c

etc.

The problem is that if we start entering all the divisors of a composite, when does Syd run out of room?

Note that it need not run out of room as fast as I understand (or perhaps misunderstand) you think it will. Storing all products of all primes in the database does indeed require space exponential in the number of primes.

On the other hand, testing a submitted composite for divisibility by all primes in the data base is only linear in the number of primes. The asymptotic behaviour is much better. Whether the implied constant is small enough to be acceptable remains to be seen.

The converse check may also be valuable: given a newly found prime factor of a specific composite, does it factor any other composite in the database?

FWIW, I'm at the start of implementing a PostgreSQL database to support my own factoring activities, not least to make production of reports and web updates much more reliable and less laborious than my present manual processes. Something I've been pondering over the last few days is whether to perform the checks described above.

Paul

[CRGreathouse]

Originally Posted by xilman

On the other hand, testing a submitted composite for divisibility by all primes in the data base is only linear in the number of primes. The asymptotic behaviour is much better. Whether the implied constant is small enough to be acceptable remains to be seen.

My estimate in post #963 was that this would take several minutes. This is too long to test every prime that's found (by a factor of at least 10), but certainly it could be done if there was a number that was suspected to be special.

[mdettweiler]

I noticed that the DB now has a worker dedicated to "Verifying primality certificates". Does this mean there is now a system in place for submitting Primo certificates on PRPs in the database?

[Mr. P-1]

Originally Posted by schickel

Sorry, that was me exploring a little bit.

Actually, I'm pretty certain it was me.

I think you'll find your issue is related to this discussion:Basically, if you report a factorization of a number by using "report factors" this way:

x = a * b * c * d

the DB ends up knowing that a, b, c, & d are factors of x, but it doesn't know the other combinations like

ab = a * b
abc = a * b * c

etc.

In this case x was already in the database, but I queried x/y where y factorised as c*d x/y got added to the database, but it did not immediately recognise that x/y had to factorise as a*b.

The problem is that if we start entering all the divisors of a composite, when does Syd run out of room?

well I don't know. There's obviously a limit to now many numbers he can store, and how many 'is a factor of' connections he can store between them. But given that the database is accepting new numbers wholesale*, I see no indication that we're near any kind of limit.

However I see no reason to add such numbers. If x fully-factored in the database, and someone queries x/y then the server could immediately return its factors. No need to store anything.

*I never entered (2^1024-1)/(2^32-1). I entered (2^(x^2)-1)/(2^x-1), and ended up adding a whole list of new ones.

[Mr. P-1]

Here's another example, currently listed as only partially factored, but with a fully factored numerator. It's even showing a scan button to let people waste workers' time on them.

[RichD]

Originally Posted by schickel

I realize that; I saw it the same way. I was wondering if you had experimented with other expressions with a "%" in them....it would be interesting to see where the "%" figures in the hierarchy of symbols while parsing expressions.

At first, I thought it was a malicious attack on the DB (it wouldn't be the first). Then I ran across the others and noticed the pattern in the expression. I think someone was trying to build a factor table with variables and it ended up being an accidental run away.

No, I haven't tried any other symbols or any modifications using "%". I didn't want my paw prints on these incase it was later found to be malicious.

[RichD]

I wonder if someone should capture a pict of the Status page for the New Year. To see how far it may have gone in the months ahead. Or capture it once every New Years Eve to see how the numbers have grown.