Broken sequences / duplicate entries - Page 3

Batalov · 2012-07-15, 02:06

You should have called it a magnificent list, or a stupendous list, or some other. Because comprehensive it was not.

Of course, the fault of taking it for a comprehensive list is entirely mine.

...Anyway, the rehashing that Syd apparently ran sometime earlier did take care of many problematic sequences.
Now it remains to be seen if that took care of all broken sequences.

Dubslow · 2012-07-15, 03:52

Quote:

Originally Posted by Batalov

Checking a sequence is ~100 times faster than retrieving it!

Yes, but during the first rebuild, my script was already putting enough strain on the DB, I didn't think asking for 9K elf files would be smart when it took a grand total of 3 sequence requests to put me over the hourly DB query limit. (Syd gave me a special exception because somebody would have to rebuild them all.)

Quote:

Originally Posted by Batalov

...Anyway, the rehashing that Syd apparently ran sometime earlier did take care of many problematic sequences.
Now it remains to be seen if that took care of all broken sequences.

Agreed. I tested one of those 22 on my list, and it appeared fine; I'll wait until the whole DB is rebuilt before checking the rest. How many errors did you spot that weren't on my list?

Batalov · 2012-07-15, 07:58

I didn't build a list, but off the top of my head 464800 was broken; its last line ~~was~~ (and still is!)

Code:

2384 .  25899582916629778656548062011125093433610618647016152268530269754868529252835232508408965054758037757047163796929148 = 2^2 * 3 * 31

The bad line is 84; it had 457427262952758559 which is not prime. This is not a new sequence - Frank's message dated June 1 had it.

It is a weird kind of brokenness: in the DB, the 85th line appears to be correct again. (so the composite was corrupted after the sequence was loaded; apparently DB is hard-linking them - not computing sigma(n)-n).

The other sequence was 410034 (this one was never mentioned on the forum). Same story, but much later - in lane 1820. The composite here was almost the same size, 505055137724945629.

Both are now reported correctly from the database (the complete .elf). I'll check the other cases if I'll find them. (but my list only goes to low 600,000s. I am not going to strain the DB by retrieving the rest or all of them again.)

Batalov · 2012-07-15, 09:33

Here's more:

Code:

608286  ...  ERROR: factor not prime: 472162738223034181 fixed
464800  ...  ERROR: factor not prime: 457427262952758559 fixed
410034  ...  ERROR: factor not prime: 505055137724945629 fixed
363270  ...  ERROR: @index 262: value != sigma - n  now fixed in i262-1760 (was extending to a fake "i1132")
344424  ...  ERROR: factor not prime: 426545107191872083 fixed
281952  ...  ERROR: factor not prime: 442003797484530521 fixed
154920  ...  ERROR: @index 1000: value != sigma - n  now fixed in i1000-1055
113160  ...  ERROR: factor not prime: 427860102068379707 fixed
97356   ...  ERROR: factor not prime: 433707931115982869 fixed

Some of them are known, and some seem new (154920)

Dubslow · 2012-07-16, 14:58

Sigh... I'm fairly sure I've found a new error.

Code:

Verifying elf 747720
Verifying index 60... 
ERROR: @index 60: value != sigma - n

I think it's new because it now "terminates" 200 lines later, so it's definitely something that I would have noticed and put on my "comprehensive" list. It's update from last week showed the following:

Code:

747720	117	1174	2^2 * 7	    2^2 * 3 * 7 * 9041 * C111	Monday 2012-07-09 @ 08:07 UTC

It would seem the underlying problems causing the errors are not solved yet.

Dubslow · 2012-07-22, 01:03

Well, all the previous errors from my list were fixed, except of course now there's one new error, in the post above.

Batalov will have to report about any possible errors with false "tails" that are larger than 110 digits. There are no such false tails of size < 110 except the one above.

Batalov · 2012-07-22, 01:27

I haven't retried to get all seqs since the database last cut me off with "too many queries". My lists end with 639354 (or else I would have found that merge).

All the n<=639354 errors were listed above.
______________

Interestingly it seems that database spends almost the same amount of queries for reporting just the last line, or 20. For 4788:
"5,115 queries to generate this page" (for the last line!)
"5,731 queries to generate this page" (last 20)

(Could be optimized, wink-wink-nudge-nudge! I appreciate that the sequnce can change at any time so you wouldn't want to cache queries. Here's a cheap idea: every node could have a cached record for a node:i+100 if it exists or NULL; then if we'd need to trace A(4788), we would jump i0(=4788) -> i100 -> i200 -> ... -> i5000 -> i5001 and until the end one-by-one. 100 could be replaced by another suitable ad hoc value.)

Dubslow · 2012-07-22, 02:01

Or perhaps render the HTML for all but the custom range option anytime a new line is added. That is to say, do cache the query, but make the cache update itself when new information becomes available, independent of people's requests.

@Batalov: How do you automate getting all the elves? When I tried with wget (the script I posted on the first page of this thread), I got a bunch of crap that wasn't an elf file.

Batalov · 2012-07-22, 02:16

If you use wget correctly, you get a proper file.

unconnected · 2013-11-29, 09:56

447432 and 888540 are broken in the FactorDB.

schickel · 2014-01-19, 02:03

As reported in the reservation thread, there are apparently problems with some sequences again....

Quote:

Originally Posted by unconnected

PS: Some sequences are broken in FactorDB - 296886, 305460, 322686, etc

Another one I just found was 337344. The last line shows up unfactored; if you click on the composite, it has a new status (at least it knows there's a problem....):

2012-07-15, 02:06	#23
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·7·677 Posts	You should have called it a magnificent list, or a stupendous list, or some other. Because comprehensive it was not. Of course, the fault of taking it for a comprehensive list is entirely mine. ...Anyway, the rehashing that Syd apparently ran sometime earlier did take care of many problematic sequences. Now it remains to be seen if that took care of all broken sequences. Last fiddled with by Batalov on 2012-07-15 at 02:27

2012-07-15, 07:58	#25
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 22406₈ Posts	I didn't build a list, but off the top of my head 464800 was broken; its last line ~~was~~ (and still is!) Code: 2384 . 25899582916629778656548062011125093433610618647016152268530269754868529252835232508408965054758037757047163796929148 = 2^2 * 3 * 31 The bad line is 84; it had 457427262952758559 which is not prime. This is not a new sequence - Frank's message dated June 1 had it. It is a weird kind of brokenness: in the DB, the 85th line appears to be correct again. (so the composite was corrupted after the sequence was loaded; apparently DB is hard-linking them - not computing sigma(n)-n). The other sequence was 410034 (this one was never mentioned on the forum). Same story, but much later - in lane 1820. The composite here was almost the same size, 505055137724945629. Both are now reported correctly from the database (the complete .elf). I'll check the other cases if I'll find them. (but my list only goes to low 600,000s. I am not going to strain the DB by retrieving the rest or all of them again.)

2012-07-16, 14:58	#27
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3·29·83 Posts	Sigh... I'm fairly sure I've found a new error. Code: Verifying elf 747720 Verifying index 60... ERROR: @index 60: value != sigma - n I think it's new because it now "terminates" 200 lines later, so it's definitely something that I would have noticed and put on my "comprehensive" list. It's update from last week showed the following: Code: 747720 117 1174 2^2 * 7 2^2 * 3 * 7 * 9041 * C111 Monday 2012-07-09 @ 08:07 UTC It would seem the underlying problems causing the errors are not solved yet. Last fiddled with by Dubslow on 2012-07-16 at 14:59

2012-07-22, 01:27	#29
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·7·677 Posts	I haven't retried to get all seqs since the database last cut me off with "too many queries". My lists end with 639354 (or else I would have found that merge). All the n<=639354 errors were listed above. ______________ Interestingly it seems that database spends almost the same amount of queries for reporting just the last line, or 20. For 4788: "5,115 queries to generate this page" (for the last line!) "5,731 queries to generate this page" (last 20) (Could be optimized, wink-wink-nudge-nudge! I appreciate that the sequnce can change at any time so you wouldn't want to cache queries. Here's a cheap idea: every node could have a cached record for a node:i+100 if it exists or NULL; then if we'd need to trace A(4788), we would jump i0(=4788) -> i100 -> i200 -> ... -> i5000 -> i5001 and until the end one-by-one. 100 could be replaced by another suitable ad hoc value.) Last fiddled with by Batalov on 2012-07-22 at 01:36 Reason: a cheap idea to cut down on # of queries

2012-07-22, 02:01	#30
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	Or perhaps render the HTML for all but the custom range option anytime a new line is added. That is to say, do cache the query, but make the cache update itself when new information becomes available, independent of people's requests. @Batalov: How do you automate getting all the elves? When I tried with wget (the script I posted on the first page of this thread), I got a bunch of crap that wasn't an elf file. Last fiddled with by Dubslow on 2012-07-22 at 02:01 Reason: s/queries/requests/

2012-07-22, 01:03	#28
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 1110000110101₂ Posts	Well, all the previous errors from my list were fixed, except of course now there's one new error, in the post above. Batalov will have to report about any possible errors with false "tails" that are larger than 110 digits. There are no such false tails of size < 110 except the one above.

2012-07-22, 02:16	#31
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2×7×677 Posts	If you use wget correctly, you get a proper file.

2013-11-29, 09:56	#32
unconnected May 2009 Russia, Moscow 101000011011₂ Posts	447432 and 888540 are broken in the FactorDB.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Broken aliquot sequences	fivemack	FactorDB	46	2021-02-21 10:46
Graphs broken for aliquot sequences on factordb	fivemack	Aliquot Sequences	4	2018-03-23 11:54
bugreport: duplicate entries	maxal	FactorDB	1	2017-11-14 15:38
Broken aliquot sequences	schickel	FactorDB	18	2013-06-12 16:09
Wrong entries in database?	Unregistered	Information & Answers	4	2008-06-28 01:50