Problem #293: v(k) computed for k<=6, absent from OEIS, and ambiguous as stated

[papanokechi]

#293 — v(k) is computable for small k, is not in OEIS, and the statement is ambiguous as written

Two separate points, one about the sequence and one about the wording. Neither
proposes an edit to data/problems.yaml yet; I'd like a maintainer's read first.

1. The statement is degenerate under its literal reading

The site states:

Let $k\geq 1$ and let $v(k)$ be the minimal integer which does not appear as some $n_i$ in a solution to $1=\frac{1}{n_1}+\cdots+\frac{1}{n_k}$ with $1\leq n_1&lt;\cdots &lt;n_k$.

With $n_1 \geq 1$ permitted, the denominator $1$ can never occur for $k \geq 2$:
$1/1$ already exhausts the sum and the remaining terms are strictly positive.
So $1$ is a minimal integer that does not appear, and the literal reading gives
$v(k) = 1$ for every $k \geq 2$.

That contradicts the quoted lower bounds ($v(k) \gg k!$, and van Doorn–Tang's
$v(k) \ge e^{ck^2}$), so the intended constraint must be $n_i \geq 2$. Everything
below uses $n_i \geq 2$.

This looks like the same class of thing as #359, so I'm reporting it rather than
silently picking a reading. If you agree, comments: "ambiguous statement" would
seem to fit.

2. Computed values

Under $n_i \geq 2$:

k	# of k-term representations of 1	v(k)
1	0	2
2	0	2
3	1	4
4	6	11
5	72	17
6	2320	103

2, 2, 4, 11, 17, 103 is not in OEIS. I searched the full sequence, the
$k \geq 3$ tail 4, 11, 17, 103, and several prose forms. The nearest entries are
A275288 (least $k$ such that some increasing sequence
with maximum $k$ contains $n$ and has reciprocal sum 1) — related but a different
quantity — and A006585, which is the count column
above, not $v$.

Verification

Each $v(k)$ was produced by two independent methods with different code paths and
different pruning:

• A — enumerate every $k$-term strictly-increasing representation of 1 in
  exact rational arithmetic, take the union of all denominators used, and return
  the least integer $\geq 2$ missing from it.
• B — for each candidate $m$ in turn, run a separate targeted backtracking
  search for a representation of $1 - 1/m$ into $k-1$ distinct unit fractions with
  all denominators $\neq m$, and return the first $m$ for which it fails.

The two agree at every $k$. The count column is an additional external check: it
reproduces A006585 (1, 6, 72, 2320, …) exactly, which validates method A's
enumerator against a source I did not write.

Suggested disposition

The oeis: possible flag looks correct and I'd keep it — a sequence plainly exists,
it just hasn't been computed or submitted. I am not submitting it to OEIS: the
values were produced by code I wrote and executed, but this repository's AI policy
(and the OEIS's) bars AI-assisted submissions, and I'm not going to launder that by
retyping the numbers. If someone here wants to submit it under their own name, the
values above are checkable in a few minutes from the description alone, and I'm
happy to hand over both scripts.

Extending past $k = 6$ is the obvious next step. $k = 7$ has 245,765
representations and is running; method B's cost is dominated by the search for the
first $m$ that fails, so the runtime is governed by $v(7)$ itself, which the
$\gg k!$ bound suggests is not small. I'll post $v(7)$ if and when it lands rather
than estimate it.

---

Disclosure: this analysis was performed with AI assistance (GitHub Copilot CLI).
All values were computed by scripts I wrote, inspected, and executed locally, each
by two independent methods, with the representation counts cross-checked against
A006585. No values were taken from a model's output. Nothing here has been or will
be submitted to the OEIS by me.

[papanokechi]

Correction and amendment — I missed a paper devoted to this problem

My original comment was written without a literature search, and there is a 2025
paper on exactly this quantity which cites #293 by number:

Wouter van Doorn and Quanyu Tang, The smallest denominator not contained in a unit
fraction decomposition of 1 with fixed length, arXiv:2512.22083
(v1 Dec 2025, v2 May 2026). MSC 11D68, 11B75.

It changes or corrects four things I wrote. My apologies for the noise; I'd rather
correct it in place than leave it standing.

---

1. My "ambiguity" report was right about the defect and wrong about the fix

I claimed the repair was to require $n_i \geq 2$. That is wrong — it would delete
the $k=1$ solution $1 = 1/1$, and the paper's argument uses $D_1 = {1}$.

The constraint $1 \leq n_1$ on the page is faithful. The degeneracy is in the
definition of $v$ itself, and the paper resolves it in its abstract:

Let $v(k)$ be the smallest integer larger than 1 that does not occur among the
denominators in any identity of the form $1 = \frac{1}{n_1} + \cdots + \frac{1}{n_k}$,
where $1 \le n_1 &lt; \cdots &lt; n_k$ are pairwise distinct integers.

One clarification, since I want to be accurate about attribution: the paper's
introduction states that "Erdős and Graham defined $v(k)$ to be the smallest integer
not contained in $D_k$" — i.e. without the "larger than 1". So this is not a
transcription slip on the site's part; the site is faithful to Erdős–Graham, and it is
the original definition that is degenerate. The "larger than 1" is the working
convention van Doorn and Tang adopt to make it non-trivial.

So the suggested edit is one clause in the definition of $v$, not a change to the
denominators. Under it my computed values are unchanged — I re-derived them with
$1 \leq n_1$ retained and "smallest $&gt; 1$" applied, and got the same sequence.

2. The page's lower bound is superseded — and the authors cannot reconstruct it

The page currently says only that "Results of Bleicher and Erdős [BlEr75] imply
$v(k) \gg k!$." Two corrections:

It is superseded. Theorem 1.1 of the paper gives, for an absolute constant $c&gt;0$,
$$v(k) \ge e^{ck^2} \quad \text{for all positive integers } k,$$
described as "the first known improvement".

More importantly, the $\gg k!$ claim itself is questioned by specialists. Quoting
the introduction directly:

On the other hand, to the best of our knowledge, no lower bound on $v(k)$ exists in
the literature. In fact, even extracting the lower bound $v(k) \gg k!$ from the
results in [1], [2] and [3] (which Erdős and Graham in [8] and [9] claim is 'easy to
see'), does not seem straightforward to us.

So the page asserts as established a bound that the only authors to work on the problem
say they cannot derive. That seems worth recording independently of the new theorem —
it is the same category as the stale-bound items in #355/#361, but analytic rather than
computational, which suggests that watchlist's frame is too narrow.

3. The upper bound is also sharpened

The page gives $v(k) \leq k c_0^{2^k}$ with $c_0 = 1.26408\ldots$ the Vardi constant.
Applying Elsholtz–Planitzer [Bull. LMS 53 (2021), 695–709, Corollary 3], the paper
obtains
$$v(k) \le c_0^{(1/5 + o(1)),2^k},$$
the prefactor and additive constant being absorbed into the $o(1)$.

4. #293 and #304 should cross-reference each other

The paper's concluding section derives the link explicitly: if $b &lt; v(k)$ then
$b \in D_k$, so some $k$-term decomposition of 1 contains $1/b$; deleting that term
leaves a $(k-1)$-term decomposition of $(b-1)/b$, hence $N!\left(\frac{b-1}{b}\right) \le k-1$.
Conversely it is Vose's bound for #304 that drives the proof of Theorem 1.1, and the
authors note that if Erdős's stronger conjectured bound for #304 holds, their lower
bound would likely improve to doubly exponential in $k$ — matching what Erdős and
Graham suggested. Neither page currently links the other.

(Also possibly of interest for the oeis column: the Vardi constant already named on
the #293 page is A076393, cited as such by the paper. I'm
not proposing it as the link — it is a constant appearing in the upper bound, not the
problem's own sequence — but flagging it in case it's wanted.)

---

$v(7) = 733$

My earlier note said $k=7$ was running and I'd post the value rather than estimate it.

$$v(k) = 2,\ 2,\ 4,\ 11,\ 17,\ 103,\ 733 \qquad (k = 1..7)$$

The 30-minute non-completion I reported was an artifact of my implementation — I was
building Fraction objects in the inner loop. Rewritten with plain integer $(p,q)$
arithmetic, the whole sequence through $k=7$ takes 0.5 seconds. That was an
implementation limit, not a reachability limit, and I should not have reported it in a
way that suggested otherwise.

Verified two independent ways, both agreeing at every $k$ from 1 to 7:

• existence — for each candidate $m = 2, 3, 4, \ldots$ in turn, search for a single
  $k$-term decomposition containing $1/m$; return the first $m$ admitting none. 0.5 s.
• enumeration — enumerate every $k$-term decomposition of 1, take the union of all
  denominators, return the least integer $&gt;1$ missing. 88 s.

Both are self-contained: neither assumes the paper's Lemma 2.1
($D_k \subseteq D_{k+1}$ for $k \ge 2$). That lemma makes the computation much cheaper
by supplying $v(k+1) \ge v(k)$, but I wanted the values to be independent of the result
they'd be cited alongside. As a consistency check they are of course monotone, as the
lemma requires.

The representation counts are unchanged and still reproduce
A006585 exactly.

One observation, explicitly not a claim: 11, 17, 103 and 733 are all prime. That is
four data points with no proposed mechanism, and reading a pattern off a small sample is
precisely the error I am trying to stop making, so I record it as a curiosity for
someone else to shoot down rather than as a phenomenon.

---

The process failure, since it may be useful to others

My screening gate for these problems checked the oeis field, git log -S on
problems.yaml, and open issues/PRs. All three measure whether the repository has
moved. None of them checks whether the literature has moved — even though every
problem page carries a disclaimer asking exactly that. Here the cost was a wrong repair,
a needless computation, and this correction; a single search on the problem's own title
would have cost under a minute. I've added a literature check as step 0 of the gate.

---

Disclosure: this analysis was performed with AI assistance (GitHub Copilot CLI). The
paper was read from the arXiv source rather than recalled, and every quotation above is
copied from it. All values were computed by scripts I wrote, inspected and executed
locally, each by two independent methods. Nothing here has been or will be submitted to
the OEIS by me.

[papanokechi]

Retraction — three of the four points I just filed are wrong

I need to withdraw most of my previous comment, about fifteen minutes after posting it.

The page already cites van Doorn–Tang. Its final two sentences read:

van Doorn and Tang [vDTa25b] have proved that $v(k)\geq e^{ck^2}$ for some constant
$c&gt;0$, and noted a close connection to [304]. In particular, if
$N(b)\ll \log\log b$ as in [304] then it is likely the methods of [vDTa25b] prove
$v(k) \geq e^{e^{ck}}$ for some $c&gt;0$.

Verified against the live page just now, and it is also present in the copy I fetched
and cached before I did any of this work.

Consequently:

• "The page's lower bound is superseded" — WITHDRAWN. It is not. The page carries
  $v(k) \ge e^{ck^2}$ already, and goes further than I did by stating the conditional
  doubly-exponential improvement.
• "Link #668 to A385657 #293 and Mark Erdős problem 1190 as solved (Lean) #304 should cross-reference each other" — WITHDRAWN. The page already
  links [304], and in more detail than I offered.
• "The upper bound is sharpened" — mostly withdrawn. The page already says small
  improvements are possible, as in [148]. All that is arguably additive is the explicit
  shape $v(k) \le c_0^{(1/5+o(1))2^k}$, and that is minor.
• My framing that I had "missed a paper devoted to this problem" — withdrawn. The
  database had not missed it. I had.

What actually survives

1. The definition is still degenerate as written, and this is unaffected by any of
the above. The page's "the minimal integer which does not appear as some $n_i$" with
$1 \leq n_1$ gives $v(k) = 1$ for every $k \geq 2$. van Doorn and Tang's abstract uses
"the smallest integer larger than 1". The suggested edit remains one clause in the
definition of $v$ — and, as in my last comment, not the $n_i \geq 2$ repair I
originally proposed, which would wrongly delete $1 = 1/1$.

2. $v(k) = 2, 2, 4, 11, 17, 103, 733$ for $k = 1..7$, computed two independent ways,
neither assuming Lemma 2.1. Unaffected. Still absent from OEIS.

3. One genuine observation remains on the bounds. The page asserts flatly that
"Results of Bleicher and Erdős [BlEr75] imply $v(k) \gg k!$", while van Doorn and
Tang — cited two sentences later on the same page — write:

to the best of our knowledge, no lower bound on $v(k)$ exists in the literature. In
fact, even extracting the lower bound $v(k) \gg k!$ from the results in [1], [2] and
[3] (which Erdős and Graham in [8] and [9] claim is 'easy to see'), does not seem
straightforward to us.

So the page states as established something the authors it cites say they cannot
reconstruct. That is a small internal tension rather than a stale bound, and it is the
only bound-related item I'd still stand behind.

What went wrong, stated accurately

In my previous comment I diagnosed this as a missing literature step in my screening
process. That diagnosis was too flattering.

I had already downloaded and cached the full statement page. The van Doorn–Tang
citation is in the last two sentences of it. I did not read to the end of a document I
was holding, then asserted what the page did and did not contain — twice, in a filing.
No amount of extra searching would have fixed that; searching was not the step I
skipped.

The correct rule is narrower and more obvious: before claiming a page omits
something, re-read that page and quote the passage the claim depends on. I've made
that a required step rather than a habit, and I've reverified the surviving points
above against the live page rather than against my own notes.

Apologies for the churn on this thread.

---

Disclosure: this analysis was performed with AI assistance (GitHub Copilot CLI). The
quotations above are copied from the live problem page and from arXiv:2512.22083, both
re-fetched for this comment.

[papanokechi]

Second correction — the definition point was already reported here, by an author, in December

Following my own advice from the last comment and actually checking the sources, I
found the problem's own discussion thread at
https://www.erdosproblems.com/forum/thread/293, which I had never opened. It contains
three comments, and between them they contain nearly everything I filed.

Most directly, from Woett (Wouter van Doorn), 22:34 on 08 Dec 2025:

Unrelated small remark on the definition of $v(k)$: we are interested in the smallest
integer larger than 1 that does not appear as some $n_i$.

That is my point 1, eight months earlier, from one of the authors of the paper. The
finding is his, not mine. The same comment also gives the sharpened upper bound
$v(k) \le kF(k) + 2 \le c_0^{(1/5+o(1))2^k}$ via [ElPl21] and $F(k)$ as in #148 — which
is the point 3 I had already mostly withdrawn.

The other two comments cover the rest:

• Quanyu Tang, 16:53 on 08 Dec 2025, proves $v(k) \le s_k$ where $s_j$ is Sylvester's
  sequence ($s_1 = 2$, $s_{j+1} = s_j(s_j-1)+1$), via the fact that Sylvester's sequence
  gives the best $n$-term Egyptian underapproximation of 1, giving
  $v(k) \le c_0^{2^k} + \tfrac12$.
• Quanyu Tang, 02:35 on 29 Dec 2025, announces arXiv:2512.22083 and states the
  Link #668 to A385657 #293 ↔ Mark Erdős problem 1190 as solved (Lean) #304 connection in both directions — my withdrawn point 4.

So: of everything in my two previous comments, the only thing not already present on
this problem's page or in its thread is the computed sequence.

What is left

$v(k) = 2,\ 2,\ 4,\ 11,\ 17,\ 103,\ 733$ for $k = 1..7$, absent from OEIS.
Two independent methods, neither assuming $D_k \subseteq D_{k+1}$; representation counts
reproduce A006585.

These also satisfy Tang's bound as a consistency check —
$s_k = 2, 3, 7, 43, 1807, 3263443, 10650056950807$
(A000058), and $v(k) \le s_k$ holds at every $k$, very
slackly. Worth noting how weak the known upper bounds are against the actual values:
$v(7) = 733$ against a bound of $\approx 1.07 \times 10^{13}$.

One thing that may still be actionable

Woett's definition comment is annotated "(The site has been updated to address this
comment.)", but the statement text still reads "let $v(k)$ be the minimal integer
which does not appear as some $n_i$" — with no "larger than 1". The visible update from
that exchange appears to be the "small improvements on this are possible as in [148]"
clause, i.e. the upper-bound half of his comment. So the definition half may have been
missed. As written the statement still gives $v(k) = 1$ for all $k \ge 2$.

Flagging it only because it appears to have fallen through a crack, and with credit to
Woett for raising it first.

Process, again

My gate checked the oeis field, git log -S, and GitHub issues and PRs. It never
checked the problem's own forum thread — which is where the maintainer, the authors, and
the actual discussion are. That is a worse omission than the one I identified last time,
because the site's page displays the comment count directly and I had that page open.

The gate now fetches /forum/thread/<n> and prints it in full before anything else runs.
I'd suggest that as the first step for anyone else working through the possible list.

Sorry again for the noise on this thread; the ratio of corrections to content here has
been poor, and the fault is entirely mine.

---

Disclosure: this analysis was performed with AI assistance (GitHub Copilot CLI).
Quotations are copied from the live forum thread. The computed values were produced by
scripts I wrote, inspected and executed locally, by two independent methods. Nothing
here has been or will be submitted to the OEIS by me.

[papanokechi]

v(8) = 27539

Following up my earlier comments on this issue (including the retraction and correction), here is one new computational result, with the verification spelled out.

Recall v(k) = the smallest integer > 1 not occurring among the denominators of any representation 1 = 1/n_1 + ... + 1/n_k with 1 <= n_1 < ... < n_k. (The "> 1" is the van Doorn–Tang convention; as noted in my earlier comment, Erdős–Graham omit it, and Woett raised this on the site forum thread on 08 Dec 2025.)

v(k) = 2, 2, 4, 11, 17, 103, 733, 27539 for k = 1..8.

The first seven are as previously reported and as in the literature; 27539 is new here. Note it is prime, continuing 11, 17, 103, 733 — stated as an observation, not a pattern; five terms is not evidence of a mechanism.

What growth this suggests

This problem asks to estimate the growth of v(k), and the computed values are the only empirical evidence available, because both flanking bounds are nearly vacuous in this range:

k	v(k)	v(k)/v(k-1)	Quanyu Tang's bound s_k (A000058)	s_k / v(k)
4	11	2.75	43	3.9
5	17	1.55	1807	1.1e2
6	103	6.06	3263443	3.2e4
7	733	7.12	10650056950807	1.45e10
8	27539	37.57	113423713055421844361000443	4.12e21

Two remarks:

1. The slack in v(k) <= s_k is itself growing doubly exponentially (3.9, 1.1e2, 3.2e4, 1.45e10, 4.12e21), so the Sylvester bound carries very little information about actual growth. At the other end, the van Doorn–Tang lower bound e^{ck^2} is vacuous until roughly k = 433 for their stated c. Every known value therefore sits in a gap spanning more than twenty orders of magnitude.
2. In an earlier comment I described the ratios as showing "two consecutive steps near 7 — not yet doubly exponential, and not obviously not." That reading does not survive k = 8: the ratio jumps to 37.57. I am flagging my own superseded remark rather than leaving it in the thread uncorrected.

The representation counts F(k) = 1, 0, 1, 6, 72, 2320, 245765 remain exactly A006585. The v(k) sequence itself appears absent from OEIS; I am not submitting it (see the disclosure below).

Verification

The result is one exhaustive scan, and its two halves need different kinds of evidence.

Positive half — every m in [2, 27538] lies in D_8. The scan runs from m = 2 upward, not seeded at 733, so it assumes no monotonicity; van Doorn–Tang's Lemma 2.1 (D_k ⊆ D_{k+1}) is deliberately unused, which keeps the result self-contained. Two independently written solvers were used (one covering [2, 20143], the other the remainder); both reproduce v(1..7) exactly and agree on hard k = 8 inputs with identical node counts, not merely identical answers.

Membership is additionally certificate-checked: a positive claim can be verified without trusting the search, by exhibiting the decomposition and summing it. This was done with Fraction arithmetic — a different arithmetic path from the integer (p, q) pairs the search uses — on a stratified sample of 93 values spanning the range, on the hardest values encountered, and on all nine values immediately below 27539. Example:

1 = 1/2 + 1/3 + 1/7 + 1/44 + 1/993 + 1/13339 + 1/4281816 + 1/19038381208

A caveat that weakens this check and should be stated: a uniform sample lands mostly on easy m, so it establishes breadth rather than hard cases.

Negative half — 27539 is not in D_8. This has no certificate, so it rests entirely on the search being exhaustive and the pruning being sound. Both solvers agree (58,317 nodes, no early exit), but that agreement is weaker than it appears, because the second solver reuses the first's pruning predicate — exactly the component a false negative would come from. A fully independent solver is not practical here: without the two-term divisor identity (pa - q)(pb - q) = q^2, the last level must enumerate a range of size about q/p, which is astronomical at depth.

So the shared components were tested directly against brute force. The load-bearing test constructs real sums of t distinct denominators >= start and confirms the harmonic-tail bound admits every one — an over-aggressive bound would discard a true solution and manufacture precisely this false negative. The exact-arithmetic and two-term routines were likewise checked exhaustively on small inputs. All pass.

I will note one incident from that testing, since it bears on how much the tests are worth: the first run reported 102 apparent failures of the two-term routine. All were one-directional (solver True, brute force False), and the fault was in my brute force, which began its loop at a = 1 and exited on the first negative remainder, so it returned False even for cases as simple as 1/4 = 1/5 + 1/20. The valid window is q/p < a <= 2q/p. The asymmetry of the disagreement is what identified which side was wrong; a reference implementation is not automatically the correct one.

I'm happy to attach the solver and verification scripts if that would be useful.

---

Disclosure: this comment was prepared with AI assistance. All numerical claims above were computed by code that I wrote and executed, and verified by the second independent method described. Per the repository's policy and the OEIS policy on AI-generated content, I am not submitting the v(k) sequence to OEIS; if anyone wishes to submit it, it should be recomputed and submitted under their own name.

[papanokechi]

Correction to my own verification argument, plus a stronger check

Two things about my previous comment. The result v(8) = 27539 stands and is now on much firmer ground, but one of the reasons I gave for believing it was wrong, and I want to correct that before it propagates.

The corroborating statistic I cited was evidence of the opposite

I wrote that two solvers "agree with identical node counts, not merely identical answers," and offered that as support for the negative half (27539 is not in D_8).

That is backwards. Two exhaustive searches produce the same node count only when their pruning is logically identical. An identical node count is therefore a dependence fingerprint — it is precisely the symptom of the shared-pruning risk I had flagged one paragraph earlier (the second solver reuses the first's pruning predicate). For the positive half it is harmless, since a witness certifies itself; for the negative half, where the only failure mode is pruning that is too aggressive, it is worthless. Withdrawn as evidence.

What actually corroborates a negative is a search that prunes less and still exhausts.

An exhaustion with no number theory in it at all

I have now re-run the case with a solver built to depend on as little as possible. It uses no factorisation, no divisor enumeration, and not the harmonic-tail bound of the earlier solvers — only:

• (L) n >= ceil(q/p) — the next term satisfies 1/n <= p/q, since the remaining terms are positive.
• (U) n <= t*q/p — the t remaining denominators are increasing and all >= n, so each term is <= 1/n and their total is p/q, giving p/q <= t/n. (This is deliberately looser than the harmonic-tail bound p/q <= sum_{i<t} 1/(start+i) used by the other solvers, so it cannot inherit an error in that bound.)
• (2) for the final two terms, enumerate a over q/p < a <= 2q/p and test whether b = q*a/(p*a - q) is an integer exceeding a. No identity, no divisors.

Each of the three is provable in one line, so a reader can check the argument's validity without running anything — which is what a claim with no certificate needs.

Result: 27539 is not in D_8. Exhausted in 59,540 nodes and 95,778,609 candidate values of a, in 90 s. Positive control: 27538 is in D_8, found immediately. This solver independently reproduces v(3..7) = 4, 11, 17, 103, 733.

An intermediate version, which kept the divisor identity (pa-q)(pb-q) = q^2 but cross-checked it against brute force whenever the a-range was affordable, agreed on 57,136 of 57,544 two-term decisions (99.3%) and also returned False. The identity-free run closes the remaining 0.7%.

One prediction that did not come true, reported because it did not

The expectation was that a weaker-pruned search would show a much larger node count, and that the size of that difference would itself be the evidence. It did not: 59,540 against 58,317, only 2.1% more, and on smaller instances the loose bound costs only 1.13x–1.40x. The two bounds turn out to be nearly equally strong on these inputs, so node-count divergence is not what carries the corroboration here. The 95.8M exhaustively enumerated a-values are. I am flagging this because the diagnostic sounded compelling and simply was not informative.

On the growth question — a diagnostic, and why it does not settle anything yet

The page speculates that v(k) "grows doubly exponentially in sqrt(k) or even k". The natural test is L(k) = log v(k+1) / log v(k), which tends to a constant if the growth is doubly exponential in k, and decreases in k if it is doubly exponential in sqrt(k).

Observed: L(3..7) = 1.730, 1.182, 1.636, 1.423, 1.550.

Calibrating each shape on k <= 6 only (i.e. on v(1..7), so the new term is genuinely out of sample) and predicting L(7):

shape	predicted L(7)	error
doubly exponential in k (L constant)	1.493	0.057
doubly exponential in sqrt(k)	1.368	0.182
observed	1.550

The eighth term is closer to the first. But this does not discriminate between them, and I want to be explicit rather than let the table imply otherwise: the gap between the two predictions is 0.125, while the training values of L themselves range over 0.548. The noise is more than four times the signal. With five usable points and L bouncing between 1.182 and 1.730, this is a diagnostic worth stating and not a result.

For reference against the page's own upper bound v(k) <= k*c_0^(2^k) with the Vardi constant: at k = 8 that gives 9.07e26 against v(8) = 27539, a slack of 3.3e22. The slack grows roughly as fast as the bound does (1.9e5, 1.0e11, 3.3e22 at k = 6, 7, 8), and van Doorn–Tang's e^{ck^2} is vacuous in this range, so every computed value sits in a very wide gap. That is the honest state of the empirical evidence on this problem's actual question.

Scripts for all of the above available on request.

---

Disclosure: prepared with AI assistance. Every numerical claim was produced by code I wrote and ran, and the negative claim above rests on the identity-free exhaustion described, not on the earlier solvers. Per repository and OEIS policy on AI-generated content I am not submitting this sequence to OEIS.