Extending Factordb

carpetpool · 2016-12-20, 23:28

There are some restricting limits on factordb.com, which I am wondering if the owner/manager of the database is willing to extend them:

Length of requested search is over 200k digits long. (Eg. You can input 200k characters into factordb.com and click "factorize" without saying the url is too long). It only works up to 8k as of now.

Also, the PRP testing for factordb should be about this length. Right now it is at 150k digits, would extending this to 200k digits be a problem? If the manager is here, I am requesting that these extensions be made unless there is a good reason not to. Thanks for hearing my suggestions about this database.

Stargate38 · 2016-12-20, 23:54

That first one would require circumventing url length limits. I don't know how you'd do that. The second one could be possible, but there is one thing that I (and possible others too) want: the ability to use the N+/-1 "Proof" buttons on numbers >10⁶⁵⁵³⁶. They keep saying "too big to be tested at the moment", and they're building up in the PRP list.

carpetpool · 2016-12-21, 03:39

Here is the error I get:

Request-URI Too Long

The requested URL's length exceeds the capacity limit for this server.

BenR · 2017-01-23, 02:50

This limit depends on the browser and server configuration. In any case, large amounts of data should not be included in the URL. Instead they should be in the body of the HTTP request. But I guess this would prevent sharing of the URL with the number in it, but I can't imagine anyone sharing such a long URL anyway.

science_man_88 · 2017-01-23, 02:57

Quote:

Originally Posted by BenR

This limit depends on the browser and server configuration. In any case, large amounts of data should not be included in the URL. Instead they should be in the body of the HTTP request. But I guess this would prevent sharing of the URL with the number in it, but I can't imagine anyone sharing such a long URL anyway.

especially since in theory you can link to it with shortened URL's and a comment about the number in question.

CRGreathouse · 2017-01-23, 08:15

Quote:

Originally Posted by science_man_88

especially since in theory you can link to it with shortened URL's and a comment about the number in question.

Neither here nor there -- when you click on the shortened URL you still need to send the full URL to the site in question (via the shortener website) or they won't know which page to display.

danaj · 2017-01-23, 11:04

For shortened urls, factordb could do this itself. For large inputs, keep a SQL table with two columns of SHA256 and number, then if given a hash as input, select number from table. There are certainly other ways to implement, and if only done for large numbers it wouldn't be too bad. But it would take some dev time and seems like a not-that-useful feature.

For input, you need do it via a post rather than URL. 10MB seems to be a normal default size and can be easily expanded, though DDOS attacks can be an issue. Some versions of IIS apparently have really small defaults.

PRP testing is probably trying to time-limit processes. Otherwise someone will get excited and start PRP testing thouands of giant inputs and tie up the cores for a long time. In theory this could be broken into smaller steps, but that is dev work and may be awkward in use. E.g. your number is 5% PRP done, putting at back of queue, wait an hour while other things run, your number is 10% done, putting at back of queue, ...

2016-12-20, 23:28	#1
carpetpool "Sam" Nov 2016 5×67 Posts	Extending Factordb There are some restricting limits on factordb.com, which I am wondering if the owner/manager of the database is willing to extend them: Length of requested search is over 200k digits long. (Eg. You can input 200k characters into factordb.com and click "factorize" without saying the url is too long). It only works up to 8k as of now. Also, the PRP testing for factordb should be about this length. Right now it is at 150k digits, would extending this to 200k digits be a problem? If the manager is here, I am requesting that these extensions be made unless there is a good reason not to. Thanks for hearing my suggestions about this database.

2016-12-20, 23:54	#2
Stargate38 "Daniel Jackson" May 2011 14285714285714285714 769₁₀ Posts	That first one would require circumventing url length limits. I don't know how you'd do that. The second one could be possible, but there is one thing that I (and possible others too) want: the ability to use the N+/-1 "Proof" buttons on numbers >10⁶⁵⁵³⁶. They keep saying "too big to be tested at the moment", and they're building up in the PRP list. Last fiddled with by Stargate38 on 2016-12-20 at 23:55

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
manually extending an assignment	dbaugh	PrimeNet	2	2014-12-02 15:31
Extending P-1 Bounds	TObject	Software	4	2012-10-10 17:42
Help extending LAN please	Flatlander	Hardware	2	2011-09-07 21:58
extending PrimeNet to the 10B range?	ixfd64	PrimeNet	5	2011-01-12 04:34
Extending the database/limits of GIMPS	NBtarheel_33	Data	9	2010-11-29 06:19

2016-12-21, 03:39	#3
carpetpool "Sam" Nov 2016 335₁₀ Posts	Here is the error I get: Request-URI Too Long The requested URL's length exceeds the capacity limit for this server.

2017-01-23, 02:50	#4
BenR Nov 2014 11₈ Posts	This limit depends on the browser and server configuration. In any case, large amounts of data should not be included in the URL. Instead they should be in the body of the HTTP request. But I guess this would prevent sharing of the URL with the number in it, but I can't imagine anyone sharing such a long URL anyway.

2017-01-23, 11:04	#7
danaj "Dana Jacobsen" Feb 2011 Bangkok, TH 2·5·7·13 Posts	For shortened urls, factordb could do this itself. For large inputs, keep a SQL table with two columns of SHA256 and number, then if given a hash as input, select number from table. There are certainly other ways to implement, and if only done for large numbers it wouldn't be too bad. But it would take some dev time and seems like a not-that-useful feature. For input, you need do it via a post rather than URL. 10MB seems to be a normal default size and can be easily expanded, though DDOS attacks can be an issue. Some versions of IIS apparently have really small defaults. PRP testing is probably trying to time-limit processes. Otherwise someone will get excited and start PRP testing thouands of giant inputs and tie up the cores for a long time. In theory this could be broken into smaller steps, but that is dev work and may be awkward in use. E.g. your number is 5% PRP done, putting at back of queue, wait an hour while other things run, your number is 10% done, putting at back of queue, ...