Terence Tao merged my pull request adding an OEIS link to the Erdős tree problem
Terence Tao merged my pull request into his GitHub database of Erdős problems, linking the tree problem to the OEIS count of trees; the link now shows on the problem's public page.
Two days after my check of every tree three sizes past the old limit finished, Terence Tao merged my pull request linking the tree problem to the OEIS count of trees in his GitHub database of Erdős problems, whose links show on erdosproblems.com. The page shows the one line that changed and explains that a merge adds a link; Tao did not review my check.
On August 6, 2026, the mathematician Terence Tao merged my pull request into his GitHub database of Erdős problems. A pull request is a proposed change to a project on GitHub, and merging it means the project accepts the change. The merge changed one line in the database's data file and added one link: from Erdős problem 993, a conjecture about trees, to the entry in the OEIS (the Online Encyclopedia of Integer Sequences) that counts trees of each size.
The public page for each problem on erdosproblems.com shows the links from Tao's database, so the link my pull request added appears on problem 993's page there. It was also my first contribution accepted into a database Tao maintains. The pull request came straight out of my check, which extended the check from every tree with up to ▲ dots to every tree with up to . Its last run finished on August 4, two days before the merge, and its description cites that check. Tao accepted the link; he did not review my check or any proof.
The database
Erdős problems are the many open questions that Paul Erdős posed over his career. The public list of them, with a page and a discussion forum for each problem, is erdosproblems.com, run by T. F. Bloom. Tao keeps a separate database on GitHub, described there as a community database for the problems on that site. Anyone can propose an edit, and Tao merges the ones he accepts. One of its columns links each problem to related sequences in the OEIS, and the database asks for help with that column in particular. A problem marked "possible" in that column is one where a matching sequence may already be in the OEIS but nobody has linked it yet. Problem 993 was marked "possible", with no sequence linked.
What I proposed, and why this sequence
Problem 993 is the conjecture that in every tree, the counts of ways to pick no dots, one dot, two dots and so on, with no two picked dots joined by a line, rise and then fall. A tree here is a network of dots and lines in one piece with no loops. The conjecture is about every tree, counted by shape, and OEIS is the count of those trees at each size. My check compared its own count of trees with that list at every size and would have failed if they differed. They matched at every size, including all trees of the largest size. The database's rule of thumb for a link is that someone interested in the problem should plausibly be interested in the sequence's page, and this one fits.
Late on August 4 I opened the pull request. I had pointed the Claude agents working under my direction to the database; they drafted the pull request text and its checks, and I had them check the text again before I approved opening it under my name. It added that sequence to problem 993's entry and kept the "possible" mark, since sequences built from the counts in the conjecture itself could be linked later.
How I followed the database's rules
The database's contributing guide asks people to compute values of the sequence and check that the OEIS entry's description really matches the problem. It also says that output from code written with AI tools has to be checked independently, and it recommends sanity checks on anything such code produces. The description of my pull request did three things.
- It showed the match: at each size my check ran, up to , the number of trees it produced equals the OEIS value. Before I opened it, the counts for the five largest sizes were compared once more with the OEIS's full published list of terms, and all matched exactly.
- It named two programs written separately: B. Reynolds's earlier check, which had reached ▲ dots (a ▲ beside a number means it has a note; the notes are listed at the end of the page), and mine. Mine rescanned his two largest sizes, 28 and 29 dots, and its tree counts there matched his exactly, with no tree breaking the pattern, before it went further. Past those two sizes, the counts rest on my program alone and on their exact match with the OEIS.
- It disclosed that my check was written and run by Claude agents (Anthropic) working under my direction, and pointed to the checks that do not depend on that code being right: the exact match with the OEIS values and the agreement with a program written by someone else. It also said that no new sequence was being sent to the OEIS; the change only links a long-established one.
What the merge changed
Tao merged the pull request on August 6, Pacific time, without comments. In the database's data file, problem 993's OEIS column went from "possible" alone to the tree-count sequence plus "possible". That is the whole change. The database table is rebuilt from that file, so the link appears in the problem's row, and erdosproblems.com shows it on the problem's page.
What the merge does not mean
A merge accepts a proposed change into the database. It is not a review of my check and not an endorsement of any proof. The database entry itself links the OEIS sequence; my check is cited in the pull request's description, which stays public on GitHub. The conjecture was open when the link was merged, and my check of trees up to a fixed size is evidence for it, not a proof.
For specialists: the pull request in detail
The pull request is teorth/erdosproblems #375, "Problem 993: add OEIS A000055 (free trees); retain possible flag". Its whole diff is one line of data/problems.yaml, in the entry for problem 993:
- oeis: ["possible"]
+ oeis: ["A000055", "possible"]The description identifies the problem as the conjecture of Alavi, Malde, Schwenk and Erdős that the independence polynomial of every tree is unimodal, quantified over free (unlabeled) trees, which A000055 enumerates. It cites two implementations: Reynolds's BrettRey/erdos-problem-993, to ▲ vertices, and my Tyorden/erdos-993-trees-n31 (named for the run to 31; it also holds the run to ), with free trees generated by gentreeg and independence polynomials by an exact integer dynamic program over subtrees. The description calls mine an independent reproduction up to ▲; the reproduction runs were at orders 28 and ▲, where the counts are identical. The per-order totals match A000055 term for term, including a() = . The database's contributing guide keeps "possible" when further sequences are plausible; the description named coefficient statistics of the independence polynomials for notable tree families as an example.
This page tells the story as of the merge on August 6, 2026; later events are on the pages linked below. One dated note: the problem pages on erdosproblems.com show this database's OEIS column under the heading "From the external database", and when I checked on October 29, 2026, problem 993's page showed the link there.
Notes on the numbers marked ▲
- Largest tree size, in vertices, at which every tree had been checked before my work: 29. Earlier checks reached this size: the forum user JakeMallen reported it on the problem's forum in January 2026, and Brett Reynolds posted code and a preprint in March 2026. My check starts where theirs ended.
These notes appear in every version of this page.
Revision history
- 2026-11-06 · corrected
The page described my work as a check of every tree up to the new limit. My own runs covered the three new sizes and some smaller ones, and the other sizes rest on earlier checks, so it now says I extended the check from the old limit to the new one.
- 2026-10-29 · created
Written later, from the pull request and my research log, to tell the step between my tree check and the later proof claims; dated to the merge.
- 2026-10-29 · corrected
The dated note said I checked the problem's page on a date later than the page itself; that date was the site's UTC stamp. It now gives the Pacific date of the check. The rationale for the link no longer says every complete check walks through this sequence, and the overlap with the earlier check is stated as the two sizes that were rescanned.
- 2026-10-29 · revised
The opening now says exactly what the merge changed (one line, one link) before why it matters, and no longer looks ahead to the later proof claims. The page says who did what on the pull request and that the rescan of the earlier check covered only its two largest sizes, and explains the ▲ mark where it first appears.
How to cite this
Tyler Satchel Orden (2026). Terence Tao merged my pull request adding an OEIS link to the Erdős tree problem. Cyborg Mathematics. https://cyborgmathematics.com/writing/erdos-database-oeis-link-merged (updated November 6, 2026)
This page has no DOI of its own. Cite the URL and the date; the revision history above keeps a dated citation meaningful.
BibTeX
@misc{orden2026erdosdatabaseoeislinkmerged,
author = {Tyler Satchel Orden},
title = {Terence Tao merged my pull request adding an OEIS link to the Erdős tree problem},
year = {2026},
howpublished = {Cyborg Mathematics},
url = {https://cyborgmathematics.com/writing/erdos-database-oeis-link-merged}
}See also
- A dropped digit sat in an OEIS entry for years until a Claude agent spotted it. What that means for anyone who copies values from reference tables.What a long-standing error in a math database means for anyone who copies reference values
- Checking an Erdős conjecture on every tree up to a size rules out small counterexamples but does not prove it. What such a check shows and how it is made.Why checking a math conjecture on every case up to a size is not a proof
- A network puzzle: pick as few points as possible so that every point is picked or linked to a picked one. A search I ran with Claude found a smaller set than any published.A new best-known dominating set for the twelfth Fibonacci cube, and a month-long run with no answer
- An Erdős conjecture: in every tree, and every forest, the number of ways to pick k vertices with no two joined rises, then falls, as k grows. I checked every tree three sizes past the old limit; it held.Checking an Erdős conjecture on every tree, three sizes further than before