[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]

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!)

has anyone else noticed the number at the bottom of the low priority queue?

[QUOTE=henryzz;172923]has anyone else noticed the number at the bottom of the low priority queue?[/QUOTE]Yes, and there are more.

If a factor is reported for a number in the queue it is not removed from the queue.

[quote=frmky;172888]This isn't appropriate. Rather than use the shared database computers, why not just grab an ECM binary and run it on your own computer? Then no one will interfere with [I]your[/I] calculation. :smile:[/quote]

I didn't do that to make progress on my own number; mine was a C85 which finished quickly, but got interrupted by the C358. I added the fake curves after that had finished. (And yes, I do have an ECM binary. I normally use it for t25 and t30ing of aliquot sequence numbers, but I resort to the workers when I haven't got time.)

[QUOTE=CRGreathouse;172917]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]

Wow. So many complications for a simple problem!

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=axn;172936]Wow. So many complications for a simple problem![/QUOTE]

Heh. :)

Syd may very reasonably decide to leave the program just as it is. But if he (?) wants to change it I'd be happy to help with coding up some of my suggestions, if he'd have it.

[QUOTE=CRGreathouse;172917]If you use accounts, people might register for several; if you restrict IP addresses, people can reset them or use proxies.[/QUOTE]
Basically whatever you do, you can't completely remove the opportunity for gaming.

[QUOTE=CRGreathouse;172917]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.[/QUOTE]
That would be tricky, because calculating the expected factors depends on how much ECM has already been done. But you don't always know.

Another way would be to have the workers report sigma values to the server (if someone uses gmp-ecm, they could just paste the whole output text in the box), and collect them. Then when a factor is reported, you could compute the smoothness of the factorization for all the recorded sigma values to see if any of them were bogus.

Making it more difficult for people to report would possibly reduce incentive for people to report at all, though, which is also bad.

[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]
Sounds good.

[QUOTE=jrk;172994]Making it more difficult for people to report would possibly reduce incentive for people to report at all, though, which is also bad.[/QUOTE]

Sorry! I was talking about ways to prevent people from making a fake worker client that reports that it performed curves when it actually did none. The generic 'report curves' button to report curves from another program seems destined to live on (if at all!) on the honor system; a system that addresses the issues underlying the priority of running curves should reduce the problem of reporting fake curves.

Checking if the number of curves reported by a purported worker program would be much easier. :)

[QUOTE=xilman;172393]I've started running a few curves at B1=11e7. It shouldn't take too long to complete a t55 as fewer than 5000 curves are needed.

Unfortunately, this number is still very hard by GNFS. Not impossible with today's technology, but decidedly non-trivial.

[/QUOTE]"This number" is the C204 from HP49(100).

Running 100 curves took 47.3 hours cpu, though it's possible the newest GMP-ECM might go a little faster. Another 400 curves are underway.

At this rate, 5000 curves is only three months cpu. Taking it to a full t60 test would take perhaps three years cpu. Neither seems too excessive to me and I think we'd want at least a t60 test before starting to search for GNFS polynomials.


Paul