Factoring database

[10metreh]

Originally Posted by Andi47

Someone has clicked "set prime" on the c163 of aliquot sequence 4788, index 2509. "Repair Sequence" doesn't fix this.

We *really* need a "re-check primality"-button.

Have you PMed Syd?

BTW, I suggest that the "Set prime" button should be removed for composite numbers. Whoever did this on 4788 clearly knows about the fact that we are working on it and wants to annoy us.

[schickel]

Originally Posted by axn

Done. Next time, just pick a large (>100000) factor of the number and resubmit. That'll change the status from CF to FF.

Can you figure out something to fix 417336?

[schickel]

Originally Posted by 10metreh

Have you PMed Syd?

BTW, I suggest that the "Set prime" button should be removed for composite numbers. Whoever did this on 4788 clearly knows about the fact that we are working on it and wants to annoy us.

Not necessarily...it may have just been a slip of the mouse.

[Andi47]

Originally Posted by 10metreh

Have you PMed Syd?

BTW, I suggest that the "Set prime" button should be removed for composite numbers. Whoever did this on 4788 clearly knows about the fact that we are working on it and wants to annoy us.

I have just emailed him.

BTW: I also suggest to remove this button for composites. AFIK, small (up to 1000 digits?) numbers are either waiting for primality check (if they have recently been entered to the DB) or already checked for primality.

And I also suggest a "re-check primality"-button.

[EdH]

Originally Posted by schickel

Not necessarily...it may have just been a slip of the mouse.

Seeing that 4788's new last line has also now been flagged as prime, I find it unlikely it was accidental.

I never see a button to allow me to set prime. It must be something limited to at least a logged in user.

Unfortunately, this now flags all numbers that merged with 4788 as ending in prime, as well.

We have noticed 4788 because we are actively working with it. Had this been a change to a dormant sequence, it might never be noticed. In fact, some may already be corrupted. This suggests an even greater need to have some primality check verify any attempt to set a number as prime. Even a simple even number check would have prevented the current (false) final iteration of 4788 to fail prime set.

[mdettweiler]

Originally Posted by EdH

Seeing that 4788's new last line has also now been flagged as prime, I find it unlikely it was accidental.

I never see a button to allow me to set prime. It must be something limited to at least a logged in user.

Unfortunately, this now flags all numbers that merged with 4788 as ending in prime, as well.

We have noticed 4788 because we are actively working with it. Had this been a change to a dormant sequence, it might never be noticed. In fact, some may already be corrupted. This suggests an even greater need to have some primality check verify any attempt to set a number as prime. Even a simple even number check would have prevented the current (false) final iteration of 4788 to fail prime set.

I think the original idea was to have it so that certain registered users were given the ability to "set prime" manually by Syd. There was no check because he simply wouldn't give it to someone he didn't trust to use it responsibly. I can think of two possibilities for what's happening now: either Syd made a boo-boo and gave it to some nefarious person pretending to want to use it for good purposes, or that nefarious person guessed the password of some trusted user.

I agree, though, a "set composite" feature would greatly help this. Also, if Syd could possibly look up who's been doing all this prime-setting on 4788, perhaps he could revoke that privilege from that user.

[Andi47]

Originally Posted by EdH

Seeing that 4788's new last line has also now been flagged as prime, I find it unlikely it was accidental.

I never see a button to allow me to set prime. It must be something limited to at least a logged in user.

Unfortunately, this now flags all numbers that merged with 4788 as ending in prime, as well.

We have noticed 4788 because we are actively working with it. Had this been a change to a dormant sequence, it might never be noticed. In fact, some may already be corrupted. This suggests an even greater need to have some primality check verify any attempt to set a number as prime. Even a simple even number check would have prevented the current (false) final iteration of 4788 to fail prime set.

Syd seems to be quite busy at the moment, his last activity dates back to Jan 9th. I have just sent him an email about the new maliciousness.

[Mini-Geek]

Originally Posted by EdH

Seeing that 4788's new last line has also now been flagged as prime, I find it unlikely it was accidental.

Who's doing this to 4788? I no longer think this can at all be "adequately explained by stupidity"!
Or maybe somebody else decided to set a new line as prime so no work would be accidentally done on the invalid sequence...if so, the above statement may be directed at the user who set the c163 prime, and not the one who set the new last line as prime.

Originally Posted by EdH

I never see a button to allow me to set prime. It must be something limited to at least a logged in user.

Indeed. Not just any logged in user, but a user with extra permissions (given out by Syd, allows the user to set PrP and Prime). I'm not sure how many people have extra permissions (I have the permissions, and I didn't ask for them or anything...probably anybody he recognized from the forums was granted permissions). If the database has any sort of logging for that sort of thing, it should be quiet easy for Syd to find out who did it. Unfortunately, Syd is apparently too busy right now to deal with it.

Originally Posted by EdH

We have noticed 4788 because we are actively working with it. Had this been a change to a dormant sequence, it might never be noticed. In fact, some may already be corrupted.

On the one hand, that's true, but on the other hand, the odds are probably equally lower that anyone would set a composite as prime on dormant sequences.

Originally Posted by EdH

This suggests an even greater need to have some primality check verify any attempt to set a number as prime. Even a simple even number check would have prevented the current (false) final iteration of 4788 to fail prime set.

I'd be all for having some quick searching for small factors when someone sets a number as prime (e.g. ECM to 15 digits, or a Quick ECM), but to run a full PRP/primality proof would defeat one of the few real purposes of the button: to let the DB know (especially for large numbers where it can't check for itself very easily) that a PRP/primality test has been run on the number and returned PRP/prime (and not composite).
Like mdettweiler said, the idea was that only trusted users would be able to do this, so checks shouldn't be necessary.
Perhaps, in addition to a "set composite" button on numbers believed to be prime, the DB should verify attempts to change the primality status of numbers by, depending on the size, (such that it will take a few seconds at most) running a primality test, a PRP test, or a Quick ECM, and seeing if the results match up with what the user is trying to say. (e.g. if a number is within the range to run a PRP test and the user clicks "set prime", it runs the PRP test and sees it return PRP, then assumes the user was really right and sets it as Prime; everything in the range of aliquot sequences would just make the DB run a full primality test since even a ) Then, since the DB does a quick sanity check, and failing that, other users can fix it, we could then extend this right to all logged in users and do away with the "extra permissions".

Just for the record, these composites are in the false 4788 sequence and listed as primes:
http://factordb.com/search.php?id=88464188 (the c163 in the real 4788)
http://factordb.com/search.php?id=97221477 (a c148 a couple lines into the false 4788 seq)
http://factordb.com/search.php?id=99126159 (line 2512 of the false 4788 seq, an even number)

[EdH]

Originally Posted by Mini-Geek

...Or maybe somebody else decided to set a new line as prime so no work would be accidentally done on the invalid sequence...if so, the above statement may be directed at the user who set the c163 prime, and not the one who set the new last line as prime...

Actually, this may indeed be the case, which could also mean that the original was accidental. I should be slower to believe ill and to post such...

In the primality checking I suggested, I was thinking of only a quick check. As you said, why bother with a button, otherwise? Does this button have an "Is this what you want to do?" check, or if selected, there's no turning back?

I was thinking of the numbers like 314718, which merge with 4788.

I just noticed that the final prime has been removed from 4788, so someone is working the issue.

[mdettweiler]

Originally Posted by Mini-Geek

Who's doing this to 4788? I no longer think this can at all be "adequately explained by stupidity"!
Or maybe somebody else decided to set a new line as prime so no work would be accidentally done on the invalid sequence...if so, the above statement may be directed at the user who set the c163 prime, and not the one who set the new last line as prime.

Indeed. Not just any logged in user, but a user with extra permissions (given out by Syd, allows the user to set PrP and Prime). I'm not sure how many people have extra permissions (I have the permissions, and I didn't ask for them or anything...probably anybody he recognized from the forums was granted permissions). If the database has any sort of logging for that sort of thing, it should be quiet easy for Syd to find out who did it. Unfortunately, Syd is apparently too busy right now to deal with it.

On the one hand, that's true, but on the other hand, the odds are probably equally lower that anyone would set a composite as prime on dormant sequences.

I'd be all for having some quick searching for small factors when someone sets a number as prime (e.g. ECM to 15 digits, or a Quick ECM), but to run a full PRP/primality proof would defeat one of the few real purposes of the button: to let the DB know (especially for large numbers where it can't check for itself very easily) that a PRP/primality test has been run on the number and returned PRP/prime (and not composite).
Like mdettweiler said, the idea was that only trusted users would be able to do this, so checks shouldn't be necessary.
Perhaps, in addition to a "set composite" button on numbers believed to be prime, the DB should verify attempts to change the primality status of numbers by, depending on the size, (such that it will take a few seconds at most) running a primality test, a PRP test, or a Quick ECM, and seeing if the results match up with what the user is trying to say. (e.g. if a number is within the range to run a PRP test and the user clicks "set prime", it runs the PRP test and sees it return PRP, then assumes the user was really right and sets it as Prime; everything in the range of aliquot sequences would just make the DB run a full primality test since even a ) Then, since the DB does a quick sanity check, and failing that, other users can fix it, we could then extend this right to all logged in users and do away with the "extra permissions".

Just for the record, these composites are in the false 4788 sequence and listed as primes:
http://factordb.com/search.php?id=88464188 (the c163 in the real 4788)
http://factordb.com/search.php?id=97221477 (a c148 a couple lines into the false 4788 seq)
http://factordb.com/search.php?id=99126159 (line 2512 of the false 4788 seq, an even number)

BTW, do you know if these fake primes are cleaned out when a factor is submitted for them? I recall that we've ran into these a few times in the past on 4788; were those cleared up on their own, or did Syd manually set them composite?

[schickel]

OK, the first time I could see as accidental, but now I have to go along with everyone else: someone is "advancing" 4788 by setting numbers as prime. (I hadn't looked at 4788 for a while, since it's on hiatus while the c163 gets factored...)

Does Syd track the IPs of submitters? If so, I think this would warrant removal of "extra permissions".

At the very least, addition of a "retest" button would go a long way toward fixing this problem....