Requests for change...

[LaurV]

We are all waiting for a better "user-management" story to be implemented... Like knowing who found a factor, how, etc. Up to now the most of this info is lost. I have contributed a lot to factoring small numbers (yoyo's script in 70-120 range) and aliquot seqs. In one year noone will remember it, including myself. Not saying about how this will be beneficial for controlling the guys like "cmd", who use to spam the DB with garbage.

Point 2 is already implemented. You can get a list with 1000 numbers to factor.

For point 3 I can't comment (I'm not doing primality proving/certifications).

[Dubslow]

I think perhaps for point 2, he meant "make it easy to find". Whenever I want to find that page, I have to go re-find your post from a few weeks ago to get the URL. (I could bookmark it, but I hardly use it anyways and speed's/my point is that we shouldn't need to bookmark it. )

[xilman]

Originally Posted by LaurV

We are all waiting for a better "user-management" story to be implemented... Like knowing who found a factor, how, etc.

Rocke Verser and I are discussing how to extend my PostgreSQL factor db (the one that holds the GCW tables I maintain and post about here) to cover more classes of integers. My DB was designed from the very start to record provenance information in a powerful and flexible manner.


Paul

[schickel]

Originally Posted by f1pokerspeed

I would like to suggest three ideas for implementation in to the FactorDB:

1) We have a page for the number of primality certificates, why can't we have one for the amount of factors each user has found? I don't suppose it would be a bad thing, would it?

The "problem" as pointed out earlier in the thread is that the DB was not originally designed as a place to store anything more than the factorization of a number. If you report a factor found by ECM along with the B1 & simga info, it will store your username under the "more info" tab (if you're signed in), but that's it. Since a lot of the info loaded into the DB at the beginning was factorization tables stored at the home site(s) of the various projects, people participating in or following particular projects will know where to find info regarding who/what/where/how factors were found.....

2) Allow the download of, say, up to 2-3,000 numbers without factors to be factored. This would allow the DB to grow a lot faster and become more comprehensive.

The issue here is that unless there are mutiple 1000s of small composites (say <102 digits), it is infeasible right now to do setup and reporting of NFS jobs automatically; and since anything over, say, 140 digits is going to take on the order of days, single manual downloads are really the only way to go.

3) Get two cores running those certificate checks - they can get stuck for 8-12 hours on a single one and it slows up the queue. If the work was done faster or even allowed to be shipped off to others then the work could be done faster.

Right now, Syd is the only person with workers that connect "locally" and do the listed work, so his resources are the bottleneck. I think he scaled back the workers since the latest round of problems cropped up; he has had as many as 8+ systems running cert checks.

Or even better, make people upload a validation file with it and save a core for use elsewhere - such as primality testing.

The only thing here is that the certificate functions as its own validation. The validation run really just consists of a trusted system checking the cert file to see if all the tests inside are correct and saying "yes" or "no". Since the system has to be "trusted", there really is no way to outsource the cert checks.

I'm sure the CPU cores could rattle through a few thousand tests every day with those sizes of numbers without a status (15k digits = about 1 second, one core = 86,000 tests per day, two cores = 176,000 tests/day) - extending the DB further.

Well, since it took ~5 secs to check one unknown number @ 18532 digits, that's in the ballpark. The only problem there is that there are 41,472,122 numbers right now that are "U" starting at 18,532 digits; that means that if they could all be dome in 15 secs, that's ~19.71 years(!!)......

[f1pokerspeed]

Well, since it took ~5 secs to check one unknown number @ 18532 digits, that's in the ballpark. The only problem there is that there are 41,472,122 numbers right now that are "U" starting at 18,532 digits; that means that if they could all be dome in 15 secs, that's ~19.71 years(!!)......[/QUOTE]

In that case, would it be possible to out-source these en masse then?

[chris2be8]

The "List of 1000 randomly chosen, small composite numbers" on the downloads page seems to select numbers with up to 109 digits. I've been using it to get a list of numbers which I then select the SNFS candidates from and factor them. But I seem to have factored most of the SNFS candidates in that range. Could it be updated to select numbers up to 110 digits?

Or does the script to generate the list have an option to select the range?

Chris

[schickel]

Originally Posted by f1pokerspeed

In that case, would it be possible to out-source these en masse then?

Actually, no. The issue here is that since the status is being checked to indicate the "official" status for inclusion in the DB (C/PrP/P), these tests have to be done on a "trusted" system.

A while back Syd tried letting some users of the DB have "extra privileges" that included setting the status of a number as "P". That didn't turn out so well......

[schickel]

Originally Posted by chris2be8

The "List of 1000 randomly chosen, small composite numbers" on the downloads page seems to select numbers with up to 109 digits. I've been using it to get a list of numbers which I then select the SNFS candidates from and factor them. But I seem to have factored most of the SNFS candidates in that range. Could it be updated to select numbers up to 110 digits?

Or does the script to generate the list have an option to select the range?

Chris

Unknown. I don't recall any mention by Syd about options when he implemented it (though that doesn't mean anything). One way to find out would be to exhaust the numbers <109 digits and see what you get then.

It looks like the floor for composites is currently at 92 digits.

[yoyo]

Originally Posted by chris2be8

The "List of 1000 randomly chosen, small composite numbers" on the downloads page seems to select numbers with up to 109 digits. I've been using it to get a list of numbers which I then select the SNFS candidates from and factor them. But I seem to have factored most of the SNFS candidates in that range. Could it be updated to select numbers up to 110 digits?

Or does the script to generate the list have an option to select the range?

Chris

Here you can fetch numbers with more digits:
http://factorization.ath.cx/listtype.php?t=3

So if you want a number with 110 digits the above form leads to this url:
http://factorization.ath.cx/listtype...=20&download=1

Request one number factor it and report it back and so on. Just specify a random number as the amount to skip.

You can also use my Perl script for it, which selects one random number and runs yafu to factor it on it and reports the factors back:
http://www.rechenkraft.net/wiki/inde...ctordb#yafu.pl

yoyo

[cmd]

opt|m|zat|on

first line ... 2 exchange with 1

[Uncwilly]

Originally Posted by cmd

first line ... 2 exchange with 1

What happened here?