Factoring database

[LaurV]

Originally Posted by VictordeHolland

This is not the first time a large batch of (useless) numbers are added to the factordb. If this starts to happen more often it might be a good idea to restrict the adding of new numbers to one each minute for unregistered users.

First, you have to define what "unregistered users" mean.

You know, the devilish guy inside of me is almost happy every time this kinda sh!t happens, because this may stimulate the DB gods to do something about those user credentials, which are totally bull there. If you type the wrong password, somebody else (called vinod thota) will get the credit, and you are not even notified, you never get any kind of credit for reporting factors (for example for aliquots, which are "needed", contrary to "random" stuff which is not - yeah, I know that is relative, therefore the quotes), moreover, every idiot can do whatever he likes there, EXCEPT fixing errors (see broken sequences due to the fact that some composite is declared prime or viceversa, we currently have few of them, but occasionally we have more), and on top of it, the mods (Syd, etc) never listen, nor reply to us.

We would heavily welcome and support some credentials system where password is password (not my results rerouted to other user if I forget to type it), credits are credits (eventually dependent of the work done on the "wanted" lists), some guys with reputation can correct DB mistakes (yes, we totally understand and agree that Syd and co. have real life, but they should delegate some mods, or at least cleaners, plumbers, broom sweepers, that can keep the house clean, that is why the jobs were invented...

We are feed up with clicking on the page and getting "not yet done" message for about 12 years now (ex: clicking on "user" in the top right, when you are logged in, to see user settings, reports, or whatever that was intended to mean when it was added to the menu 12 years ago).

[wpolly]

Indeed. The last post of Syd on this forum dates back to more than two years ago. The database in its current form really looks like an old and rusty machine without maintenance.


Anyway, here are some changes that I would like to see happen (and I'd like to volunteer to implement some of them):


1. Convert n## to appropriate p(n)# when passing an expression to PFGW. (Or maybe get rid of this ## operator permanently. It is redundant anyway.)

2. Maybe add more functions to the current expression parser: The most important ones would be Generalized Lucas numbers, which cannot be written as a short expression in the current parser.

3. A definition of "useful" numbers when adding to the database; The rate of adding "useless" numbers to the database shall be severely limited, maybe to one or less per second. A new entry is considered to be "useful" if at least one of the following criterion holds:

• It is a factor of a known composite number already in the database.
• It has an expression that is shorter than a simple decimal expansion.
• It is related to known entries in other ways (e.g. Aliquot sequences).

4. Ability for user-side correction of database errors (e.g., combining duplicate entries by inputting two database IDs, or submitting factors to false PRP.....)
5. This maybe hard to implement, but I'd like to see some kind of auto-synchronization with Jonathan Crombie's factor collection (myfactors.mooo.com), maybe once per week.

[MisterBitcoin]

Taking composites <85 digits, until status page is up again.
The script started with getting lots of C55.

[RichD]

The following URL provides the list of composites distribution report.

http://factordb.com/stat_1.php

[MisterBitcoin]

Originally Posted by RichD

The following URL provides the list of composites distribution report.

http://factordb.com/stat_1.php

I didn´t suggested that this is still working. oO
There is an HUGE mess of C90 up to C99, that need clearing. I´m able to take all with <95 dd within a few days, above will takee some time.

Has anyone a idea about the source of this massive composite series?
Edit: I checked some of them, some have small factors. Let´s see how this turns out.

[EdH]

I have several machines running in the >78 dd region. They are working at 79 dd+60 candidates, so working c90 and up is a good idea ATM. Although, I'm currently not getting further than 82 digits, I would hope to clear up to 89 and then work there for the near term.

[MisterBitcoin]

Originally Posted by EdH

I have several machines running in the >78 dd region. They are working at 79 dd+60 candidates, so working c90 and up is a good idea ATM. Although, I'm currently not getting further than 82 digits, I would hope to clear up to 89 and then work there for the near term.

7 workers are running in the range from 90 dd up to 99 dd.

[SethTro]

It would help reduce my confusion if you could add one or both of these

1. Current server time to the status page
2. Relative age on creation time

Currently the "Create time" in more information is hard to parse.
"Create time: January 3, 2020, 1:56 am" isn't super useful when it's Jan 2nd in my timezone.
"Create time: January 3, 2020, 1:56 am (4 hours ago)" and "Create time: May 17, 2018 (700 days ago)" would be much more useful.

Thanks for consideration.

[MisterBitcoin]

Lots of C83 in the DB, gonna remove some of them. ^^

[richs]

Originally Posted by MisterBitcoin

Lots of C83 in the DB, gonna remove some of them. ^^

I’ve been plugging away at the C83’s with one core of an i-3, but feel free to work on them.

[MisterBitcoin]

Originally Posted by richs

I’ve been plugging away at the C83’s with one core of an i-3, but feel free to work on them.

Most of them require SIQS, so i am at ~50 to 60 canidates per hour.
Using an offset from 5k, so we shouldn´t get into trouble :)
Right after mentioning it. Karma~

 Worker collisions...........: 1