mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   FactorDB (https://www.mersenneforum.org/forumdisplay.php?f=94)
-   -   Factoring database (https://www.mersenneforum.org/showthread.php?t=11119)

Syd 2009-05-13 01:02

Thank you for all your suggestions and bug reports!

I did several changes. First of all, the t35 and t40 VHL are now limited to 350/250 digits, hope this helps to keep the queue short.

The next one is an option to upload several files at once (below the "report factors" box). The files are queued up for inserting, so it probably wont cause problems.

And finally a new sequence (A002144), more will follow soon!



[quote=fivemack;172901]I agree with CR; maybe ten curves with limit 10k is a reasonable thing to have a factor repository do (since that happens in about the time it takes to load a Web page on a not-very-fast connection), but anything bigger should be done elsewhere and have the factors reported.[/quote]

agreed. Will add this one soon.

[quote=CRGreathouse;172918]Don't get me wrong: I like the current setup and have used it to find factors, some not that small. I just recognize it as a special gift from Syd to the community.

I do hope that even if Syd decides to stop providing this excellent resource, he'll find some way to preserve the factorizations. (No, I don't have any good ideas here!)[/quote]

Just in case I have to stop it and cant send the factorizations to someone else, or I loose the database and all my backups at once - who knows - here is a complete database dump:

[URL]http://factorization.ath.cx/factorization.ath.cx.sql.bz2[/URL]

This one is huge, please keep the number of downloads small.
I'll update this one from time to time.

[quote=smh;172929]Yes, and there are more.

If a factor is reported for a number in the queue it is not removed from the queue.[/quote]

Got it. They are removed once a worker looks at them.

[quote=CRGreathouse;172917]Everything other than very high limits finishes very quickly, so I agree that there's no good reason to restrict those.

Personally, I'm amused by the current setup: anyone can do anything to the jobs. If that could continue it would be nice. But restricting it otherwise might be sensible as well. I've been trying to think of what way would be most sensible: restricting a person to a limited amount of power (CPU-hours), or a number to an amount of power, or various schemes that would reward people for contributing workers, etc. (Contributing X CPU-hours might give preferential access to aX CPU-hours later, for 0 <= a <= 1, allowing people to time-shift. Of course there would be no guarantee that it would ever be redeemable -- Syd might move to Outer Slavbeckstania where there is no Internet access -- but that's a chance I think many would take.)

If you use accounts, people might register for several; if you restrict IP addresses, people can reset them or use proxies. Faking workers is harder but could be done; checks to see if the number of factors found is close to what would be expected could be implemented if that was a problem. Requiring registration does lower the marvelous openness of the project in its current state, but it would have certain advantages. For me, the biggest one would be the potential to time-shift: a person might contribute 1,000 CPU-hours if I knew that they would (probably) be able to use 100 CPU-hours (over, say, 6 to 30 hours) to get 'important' factoring done quickly.[/quote]

Using accounts is a neat idea. I'll try too add it, maybe with a higher priority for registered users.


[quote=10metreh;172971]Just spotted another aliquot sequence bug, this one on sequence 230688, line 189. The database is reading the number as if it had been squared, (although this does not happen in the elf file that I reported) and this results in the next line going completely awry. Check on the composite from line 189 itself ([COLOR=black]775831688224357875486398092[/COLOR]): it gives the factorization of 775831688224357875486398092^2 along with "Error: Error on ID 35640306 ([URL="http://factorization.ath.cx/search.php?id=35640306&repair=true&detail=1"][COLOR=#0000ff]Repair[/COLOR][/URL])". When you click on the "Repair" link it seems to be fixed, but I have to re-report the factors for the whole sequence.[/quote]

There are still a lot of inconsistencies, I hope I corrected most of them.


PS: Accidently flushed the work queue, in case you wonder

10metreh 2009-05-13 06:23

Every page on the site is blank.

Andi47 2009-05-13 06:54

[QUOTE=10metreh;173385]Every page on the site is blank.[/QUOTE]

For me too.

kar_bon 2009-05-13 07:52

empty pages are an indicator that Syd installed a password login (.htaccess).

jrk 2009-05-13 07:58

I wonder if it has anything to do with:
[QUOTE=Syd;173363][URL]http://factorization.ath.cx/factorization.ath.cx.sql.bz2[/URL]

This one is huge, please keep the number of downloads small.[/QUOTE]

jrk 2009-05-13 08:00

[QUOTE=kar_bon;173389]empty pages are an indicator that Syd installed a password login (.htaccess).[/QUOTE]
Another possibility is an error from a language interpreter being redirected somewhere else. User gets a blank page and something is written to error_log.

Syd 2009-05-13 10:18

Nothing to worry about. My router had a little hiccup and cut the ssh tunnel where the page runs through. Happens once a year or so .. :smile:

mklasson 2009-05-13 12:44

Syd, submitting factors seems horribly slow, often taking several minutes to complete even the smallest submission.

I'm just guessing here, but is it because the workers must do some crunching on each submitted number before you accept the next one? In that case, maybe you could consider accepting the entire submission first and just queue the crunching for later? Or perhaps prioritise what little submission crunching you want to do?

In any case, having to wait a long while for the submission to complete is a bit annoying so anything you could do to alleviate the problem would be much appreciated.

Right now I'm only getting "500: Internal Server Error", but I assume that's a relapse of this morning's problems.

mklasson 2009-05-13 15:43

It would be nice if you could see when a factor was submitted (i.e. date and time of submission) somewhere on its details page.

CRGreathouse 2009-05-13 16:45

[QUOTE=mklasson;173427]It would be nice if you could see when a factor was submitted (i.e. date and time of submission) somewhere on its details page.[/QUOTE]

Eh, maybe. I think I prefer theslimmer database size of dropping as much information as possible. (I hope that the number of ECM curves done on a number is removed once it's factored, for example.)

Syd 2009-05-13 23:24

I had to remove the download, 23 downloads killed most of my traffic quota ..


All times are UTC. The time now is 22:20.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.