Wrong submissions

[RedGolpe]

Hi all.

While working on the aliquot sequence project, my program failed to spot a small composite so my aliquot sequence derailed and I only noticed the error after uploading the results, thus uploading 820 factorizations of "useless" composites.

I understand from previous messages that spam is an issue on factordb, and though I doubt my submission of already factored numbers is actually a problem, I have a list of the numbers uploaded if someone wants to purge them.

Thank you for maintaining factordb and sorry for the mess

[EdH]

I don't think that's any kind of problem, even if you hadn't supplied factors. The number is minuscule compared to how many new numbers are added to the db continuously and, as I understand it, the db exists to compile composites and primes.

As to the missing of a smaller composite, I had experienced this when working with a script that would grab the last number on a retrieved last line page. I had to rewrite the script to look for the last "composite" on the page. It's been a while since I used that script, so I don't remember the details fully, but I think I looked for the blue highlight (<font color="#002099">).

Edit: As to the spam issue, that shows up as multi thousands of numbers added in waves and the db just accepts them, happily adding them to its list of numbers. You don't fit that description.

[RedGolpe]

Thank you for the clarification.

Originally Posted by EdH

As to the missing of a smaller composite, I had experienced this when working with a script that would grab the last number on a retrieved last line page. I had to rewrite the script to look for the last "composite" on the page. It's been a while since I used that script, so I don't remember the details fully, but I think I looked for the blue highlight (<font color="#002099">).

I failed to detect a composite output by my own program, not by factordb. It was a very special case and it's now fixed, but obviously I can't be 100% sure I won't find other bugs.

[kruoli]

As far as I understand the "bad" numbers you uploaded only derailed because of one error? That means, if one would step on one of your intermediate results after that error, the aliquot sequence from that point on is alright, correct?

[RedGolpe]

Originally Posted by kruoli

As far as I understand the "bad" numbers you uploaded only derailed because of one error? That means, if one would step on one of your intermediate results after that error, the aliquot sequence from that point on is alright, correct?

Almost. In fact, we can say I uploaded the first 820 terms of the aliquot sequence starting with 260980552655644516569325929485089843584615065409837402108167278934292990602998173402281447690. Unfortunately, after checking that sequence on factordb, I discovered another instance of the bug in question, so we only got the first 447 terms, along with the first 372 terms of sequence 16439450490798386766697893535628678097675104310467179754114132439038118655211466664624254460919444. I guess it'll be a while before we open reservations on those ranges but I'm happy to have saved some CPU time to my descendants.

[LaurV]

Originally Posted by RedGolpe

I guess it'll be a while before we open reservations on those ranges but I'm happy to have saved some CPU time to my descendants.

Unless they merge with some very low-starter sequence, haha, you never know.

Your x hundred fixed factors are no bother for the FDB. No harm done. And the fact you came forward is a big point for you.

Harm is done by some idiots who uploads hundred of thousands of small numbers, and if possible, with variables (like 2^n+773, random example) for which the DB elves crack and crack... as long as you look to the sequence, until the length reaches the elves' limit.