Errata<\/h2>\n\n\n\n

Every time I wrote I should have written . This will be corrected in the final version.<\/p>\n\n\n\n

The pigeonhole upper bound is perhaps better written , since it arises as , where is the totient function. <\/p>\n\n\n\n

Quality of the data<\/h2>\n\n\n\n

After commenting, Tom\u00e1s Oliveira e Silva sent a follow-up email prompting me to belatedly flesh out this post a little.<\/p>\n\n\n\n

After computing the first 100000 values independently, he found one discrepancy. 221000.dat has<\/p>\n\n\n\n

53829 1.035945566231253e-8 6045 19754 30497 38849<\/code><\/pre>\n\n\n\n
but Tom\u00e1s has<\/p>\n\n\n\n
   53829 0.0000000043404367309945397      0      0  15622  31244 31244<\/code><\/pre>\n\n\n\n
which agrees with the output of search.c<\/p>\n\n\n\n
53829 4.3404373281240489e-09 0 15622 31244 31244<\/code><\/pre>\n\n\n\n
So what’s going on here?  The answer necessarily includes the fact that search.c was not used to produce that line of 221000.dat.  The history is that the data set and the search program developed together over time.  The final version of search.c is (hopefully) better than the earliest versions in several ways, including a considered approach to avoiding zero sums rather than an optimistic one, and a change in the enumeration order to notice when we’re about to generate a lot of very long sums and skip over them.  The very earliest searches weren’t even done in C; I used Haskell, which is my usual go to for combinatorics, but wasn’t the best fit for this naturally expressed brute force loop.  In any case, I didn’t rerun the whole search using the final program because of the cost of producing the data.  I’ve been at peace with the risk of errors because I was using the data to suggest patterns to investigate rather than relying on it for any proofs, but I should have been clearer about what I did.<\/p>\n\n\n\n
Putting my archaeologist’s hat on, we can tell that the line in 221000.dat isn’t from the latest version of search.c due to the different output format.  In fact, there’s a break between the two formats at .<\/p>\n\n\n\n
119999 1.6533522139157386e-9 15853 43211 70569 86422\n120000 3.4249738497730593e-10 20224 40448 77495 82953\n120001 8.4593861872462649e-10 10962 39803 71356 79549\n120002 1.4113956883942480e-10 19401 45243 71085 90486\n120003 1.3630084760844623e-10 10265 44351 65134 85917\n120004 5.3309237833505616e-10 9345 39651 69957 79302\n120005 2.1493219522622943e-09 6408 39397 67265 79033<\/code><\/pre>\n\n\n\n
This means that I might have used Haskell as far as 120000 (I might also have used C with a different output format), but I didn’t use it any later.  In fact the incorrect line matches the output of the Haskell search exactly, so the error probably comes from a bug in the Haskell.  My first guess, given the correct form of the optimal configuration for 53829, is that I had an off by one error in an index preventing me from looking at , but after revisiting the source code I don’t think that’s it.  As an early version of the guard against pointless searching I have the line<\/p>\n\n\n\n
bestCompletions bestGuess a b = if length > 2.0 then [] else [t | t@(_,a,b,c,d) <- candidates''', not $ zero a b c d]<\/code><\/pre>\n\n\n\n
The error here is that the cutoff for “too long” needs to be 2 plus the shortest thing seen so far, not 2.  (Not counting the triple-prime in a variable name as an error.)  The correct configuration for 53829 is exactly a situation in which the sum of the triple has length just over 2, so the Haskell search couldn’t see it.<\/p>\n\n\n\n
I’m going to generate the data from 1 to 120000 again in case there are more errors of this type.<\/p>\n","protected":false},"excerpt":{"rendered":"
arXiv Code and data search.c 221000.dat plot5.ggb – Geogebra notebook geo5.sh – awk one-liner to format array to input parameters to Geogebra Errata Every time I wrote I should have written . This will be corrected in the final version. The pigeonhole upper bound is perhaps better written , since it arises as , where … <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"_links":{"self":[{"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/posts\/583"}],"collection":[{"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/comments?post=583"}],"version-history":[{"count":0,"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/posts\/583\/revisions"}],"wp:attachment":[{"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/media?parent=583"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/categories?post=583"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/babarber.uk\/wp-json\/wp\/v2\/tags?post=583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}