Edges needed to be removed to make graph bipartite

[Elijah Beregovsky]

How many edges need to be removed from a triangle-free graph on n vertices
to make it bipartite? Erdős asked this question and conjectured that n^2/25

edges would always be sufficient. (See https://www.erdosproblems.com/23)

I've decided to calculate the first terms of this sequence by downloading the maximal triangle-free graphs from https://houseofgraphs.org/meta-directory/maximal-triangle-free and running them all through a mixed integer linear programming solver (aka writing some terrible Python code 😃). I've got the following values so far:

n    a(n)

1    0

2    0

3    0

4    0

5    1

6    1

7    1

8    2

9    2

10   4

11   4

12   5

13   6

14   7

15   9

As there are over 25 thousand mtf graphs on 16 vertices, a(16) is likely to take a couple hours, so I decided not to wait for it (it's currently on iteration ~4800 and going quite slowly), and a(17) may be out of reach for me without optimizing the code.

I would love it if someone verified these values before the sequence (A389646) is published.

PS

Here's my MILP translation of the problem:

Take a graph. 

Create a boolean variable for every vertex and every edge of the graph.

For every edge e = (v,w) add the following four constraints to the solver

        e + v - w >= 0
        e - v + w >= 0
        -e + v + w >= 0
        e + v + w <= 2

This has the effect of forcing e to be equal to v xor w. This seems to me like an excessive number of constraints for such a simple function, but I couldn't come up with a shorter & cleaner way of doing this.

Maximize Sum(e)

[Charles Greathouse]

I don’t have a better algorithm, but I certainly hope you submit the sequence! It looks very nice.

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD-2a7GMYt7E0yCe7uHS7wCLqedfJ2wMMHy7gUW7f8yKxrBuDQ%40mail.gmail.com.

[Elijah Beregovsky]

Update: a(16) has finished running and it is 9. Will try a(17) overnight, but I don't expect it to finish in any reasonable timeframe

[Rob Pratt]

Because you are maximizing sum(e), you can omit the first two constraints, which will naturally be satisfied at optimality.

---

From: seq...@googlegroups.com <seq...@googlegroups.com> on behalf of Elijah Beregovsky <elijah.b...@gmail.com>
Sent: Thursday, October 9, 2025 4:45:11 PM
To: seq...@googlegroups.com <seq...@googlegroups.com>
Subject: Re: [SeqFan] Edges needed to be removed to make graph bipartite

 

Update: a(16) has finished running and it is 9. Will try a(17) overnight, but I don't expect it to finish in any reasonable timeframe

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD-2a7HTQ5Gh_Vb3P4LwUKEXo-QE%3D6PhRki9D1G-UW9xC5mqBg%40mail.gmail.com.

[Rob Pratt]

You can also break symmetry by arbitrarily fixing the value of one vertex variable.

---

From: Rob Pratt <robert.wil...@gmail.com>
Sent: Thursday, October 9, 2025 5:22 PM

To: seq...@googlegroups.com <seq...@googlegroups.com>
Subject: Re: [SeqFan] Edges needed to be removed to make graph bipartite

[Rob Pratt]

You can also break symmetry by arbitrarily fixing the value of one vertex variable.

---

From: Rob Pratt <robert.wil...@gmail.com>
Sent: Thursday, October 9, 2025 5:22:38 PM

To: seq...@googlegroups.com <seq...@googlegroups.com>
Subject: Re: [SeqFan] Edges needed to be removed to make graph bipartite

[D. S. McNeil]

Fun problem!  I agree with all your numbers and propose a(17)=9 as well.

IIUC, you don't have to run MILP on every graph, only enough to constrain the resulting value.

That is, you can use a more heuristic approach (I used a mostly greedy one) to quickly show that almost all of the graphs only need a candidate number of removals X or below, by explicitly constructing the deletions.  Then you only need to prove that X works for any which the fast approach didn't pick up.  This shows a(n) <= X.

Then you prove that X-1 doesn't work for at least one of them where you found a solution with X, showing a(n) >= X.  This squeezes a(n) = X.

This way we only need to use the heavy machinery for a handful of graphs per n.

Doug

On Thu, Oct 9, 2025 at 3:26 PM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

[Elijah Beregovsky]

a(17) has finished running, and it is 10. Took around 14 hours without Rob's optimizations (I saw them only when I woke up, and by that point the calculation was around 2/3 done and I just left it alone for the day. Would have taken around 1.5 times faster with them.) Here's one of the graphs that cannot be bipartitioned in nine cuts:

The graph's edges: [(0, 2), (0, 5), (0, 7), (0, 8), (1, 3), (1, 4), (1, 6), (1, 8), (2, 4), (2, 6), (2, 9), (2, 12), (2, 13), (3, 5), (3, 7), (3, 9), (3, 12), (3, 15), (4, 7), (4, 10), (4, 11), (4, 14), (5, 6), (5, 10), (5, 11), (5, 16), (6, 7), (6, 14), (6, 15), (7, 13), (7, 16), (8, 9), (8, 11), (8, 13), (8, 14), (8, 15), (8, 16), (9, 10), (10, 12), (10, 13), (10, 15), (11, 12), (12, 14), (12, 16)]

The edges that were cut to make it bipartite: 

[[ 0  5]
 [ 0  8]
 [ 3  5]
 [ 3  9]
 [ 3 12]
 [ 5  6]
 [ 7 16]
 [ 8  9]
 [ 8 13]
 [10 15]]

PS:

I think I'll translate the problem into SAT, both to be able to implement an early stopping criterion as Doug suggested and just for general speed-up that comes with using CP-SAT as opposed to SCIP, and attempt a(18). I think with all optimizations it will take me just one or two days. Sadly, a(19) is totally out, because House of Graphs doesn't have a file with all mtf graphs on 19 vertices, but only their (pretty huge) number

[D. S. McNeil]

Oof, you're right!

I had the signs flipped here:

cross[v] += -1 if color[v] == cu else 1

which meant that each neighbour's count of opposite-colour neighbours was backwards, so the algorithm thought some flips improved the cut even when they didn't, giving negative deletion counts (!) which of course weren't sanity-checked against the deletion set itself, because what could possibly go wrong?

Doug

[Elijah Beregovsky]

Translated the problem into SAT, basically the same as with MILP, except I added an explicit XOR(e,v,w)==true constraint (note, that it inverts e, and turns this into a minimization problem). And then I switched the problem from an optimization to constraint satisfaction, as Doug suggested — instead of minimizing sum(e) I now added the constraint sum(e) <= current worst cut. We don’t need to know the very best cut, we just need to know a certain number of edges is enough. It sped up the calculation by an order of magnitude, thanks, Doug! Now a(18) is running, and I project that it’ll take ~13 hours in total. Current bound after 1 hour is a(18) >= 11

Elijah

[Robert Gerbicz]

For a given graph there is an algorithm that works in only O(n*2^n) time.

Of course a(n) is an increasing sequence.
Say that you have a lower bound a(n)>=B, and a triangle-free G graph on the v[1],...,v[n] vertices.

Do a depth search. For each k=1..n depth do:
Color v[k] by blue or red, and for each i=1,..,k-1, if v[i]v[k] is an edge of the graph then you need to delete this edge if color of v[i] and v[k] is the same.
If the deleted number of edges is already larger than B, then this can not give a solution.
If reached k=n, then you get a good coloring using at most B deleted edges (and you can break the search), and if k<n, then increase k.

If you have not found a solution for a given G graph, then this gives that a(n)>B, so you can increase the B lower bound, and repeat the process (only for the given G graph, to see if the new lower bound is good or not).
To make it faster you could probably choose first that blue/red coloring on each depth that gives the lower deleted number of edges.

Elijah Beregovsky <elijah.b...@gmail.com> ezt írta (időpont: 2025. okt. 11., Szo, 10:09):

Translated the problem into SAT, basically the same as with MILP, except I added an explicit XOR(e,v,w)==true constraint (note, that it inverts e, and turns this into a minimization problem). And then I switched the problem from an optimization to constraint satisfaction, as Doug suggested — instead of minimizing sum(e) I now added the constraint sum(e) <= current worst cut. We don’t need to know the very best cut, we just need to know a certain number of edges is enough. It sped up the calculation by an order of magnitude, thanks, Doug! Now a(18) is running, and I project that it’ll take ~13 hours in total. Current bound after 1 hour is a(18) >= 11

Elijah

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/A0489B28-268B-4B35-98C9-09D6DC1EE30D%40gmail.com.

[Brendan]

a(18)=12 probably.

I wrote a crude heuristic in C.  Basically, choose a random vertex and move it to the other side of the cut if that makes the cut bigger (or equal) and repeat for some limited amount of time.

It took less than half a second (M3 Mac) to show that a(16)<=9 and a(17)<=10.

For a(18), it found an upper bound of 11 for all but 2 graphs, in about 1.5 seconds total.  I tried those 2 graphs without success for quite a while so I expect they are witnesses for a(18)=12.

Here are the graphs:

Q?rOpOGHN`BAHh@rMCKE`sSbac?
QoA[rMX]BLKs_V@kN?ZoE]?oEow

If one or both of these require removal of 12 edges to be bipartite, then a(18)=12.

Meanwhile, I'll try to get hold of the graphs with 19 vertices.

Brendan.

On Sat, Oct 11, 2025 at 7:09 PM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Translated the problem into SAT, basically the same as with MILP, except I added an explicit XOR(e,v,w)==true constraint (note, that it inverts e, and turns this into a minimization problem). And then I switched the problem from an optimization to constraint satisfaction, as Doug suggested — instead of minimizing sum(e) I now added the constraint sum(e) <= current worst cut. We don’t need to know the very best cut, we just need to know a certain number of edges is enough. It sped up the calculation by an order of magnitude, thanks, Doug! Now a(18) is running, and I project that it’ll take ~13 hours in total. Current bound after 1 hour is a(18) >= 11

Elijah

[Brendan]

Now I have the program for generating maximal triangle-free graphs.

a(19)=13 if any of the following 4 graphs really need 13 edges removed to make them bipartite:

RHO\I_ge?FwchOiACI_EiEB`QbeH@o
RHO\M_ge?Fw_sGEBASeHAiAGBUXIf?
RHO\I_ge?FwchOsGT@?SM?tWDoqdD?
RHOXMageEGGUAqs_RODGK?}ChLAHdG

Brendan.

On Sat, Oct 11, 2025 at 7:09 PM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Translated the problem into SAT, basically the same as with MILP, except I added an explicit XOR(e,v,w)==true constraint (note, that it inverts e, and turns this into a minimization problem). And then I switched the problem from an optimization to constraint satisfaction, as Doug suggested — instead of minimizing sum(e) I now added the constraint sum(e) <= current worst cut. We don’t need to know the very best cut, we just need to know a certain number of edges is enough. It sped up the calculation by an order of magnitude, thanks, Doug! Now a(18) is running, and I project that it’ll take ~13 hours in total. Current bound after 1 hour is a(18) >= 11

Elijah

[Brendan]

In about 13 minutes, I bipartitized all the maximal triangle-free graphs with 20 vertices

by removing 14 edges, except for one graph that my heuristic couldn't do with less than

15 edges in a million attempts.  It is here:

SLoXOogE@OITSiSiSi}NohTrFwDImENo?

This is a vertex-transitive graph of 20 vertices, degree 8 and automorphism group 79626240.

It is listed here:  https://houseofgraphs.org/graphs/1811

If this graph needs 15 edges, then a(20)=15.  If 14 edges are enough, then a(20)=14.

If (to my big surprise) 13 edges are enough, let me know and I'll provide more candidates for 14.

Brendan.

[Brendan]

CORRECTION.

On 20 vertices, I can do everything with 14 edges, except for this one graph that

I can't do with less than 16 edges (not 15).

I ran my heuristic for 10,000 steps from 10 million random starting points and it

never managed less than 16 edges.

Brendan.

[Elijah Beregovsky]

Wow, Brendan, this is a helluva speedup, kudos! I checked your graphs with my SAT solver, the a(18) one is only doable in 12 edges, all four a(19) ones — in 13, and the one for a(20) — in 16. I will still finish running my code for a(18) to check if your heuristic missed anything, but I think you’re right.

Elijah

[Victor Miller]

I wonder if you can speed this up by using a result in this paper: 

https://www.sciencedirect.com/science/article/pii/S0012365X16300085

They show the following: if G is a graph on n vertices define the unsigned Laplacian matrix as

L=A+D, where A is the adjacency matrix of G and D is the diagonal matrix of degrees. Let q_n denote the smallest eigenvalue of L. Then, D_2(G), the minimum number of edges that need to be removed to make G bipartite satisfies:

D_2(G) >= q_n * n/4

On Sat, Oct 11, 2025 at 07:29 Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Wow, Brendan, this is a helluva speedup, kudos! I checked your graphs with my SAT solver, the a(18) one is only doable in 12 edges, all four a(19) ones — in 13, and the one for a(20) — in 16. I will still finish running my code for a(18) to check if your heuristic missed anything, but I think you’re right.

Elijah

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/462BC827-45F6-42F7-86D7-AA2D2AB0716A%40gmail.com.

[Elijah Beregovsky]

Update: a(18) is indeed 12 according to my calculations

Elijah

[Brendan]

a(21)=16, the same as a(20).

a(22)=17

I wrote an exact solver to test the few graphs that the heuristic failed to eliminate.

I used a Gray code to make the cuts in minimum change order.

The main loop is just 10 lines of C.

For 21 vertices there are 6 graphs that need 16 edges and none that need 17 edges.

Here are the 6 graphs.

TLoXOogE@OB?SiSiITDInp~AdVeNwDInBF{?
THO\Mag?xQ?[IO?wTAlOisFpQiu_}E_}@Qio
THO\Mag?xQ?[HO?wSalOisFpQiu_}E_}@Qio
THO\I_ge?FWchOOAqCDOO@WSYDACd`?pW`T_
THO\MageEGDHHSIQCiAHiPLPQf_sTqdN?YIw
THO\I_ge?FWchOOCcIcHBE`O_W\OQA_T?B_F

For 22 vertices, there are 338 graphs that need 17 edges and none that need 18 edges.

Here is a sample that need 17 edges (let me know if you want the full set).

UHO\M?geAC_lsGEQ?mDGA?drO?iDa?bOpQCoI@go
UHOXM_J?Mc?JhHscTAEG_i@?gDUH?GIoWChgC_m_
UHOWE_JhMcT??te?_ha@Bp_?OSXU?IKI?YO_?Iaw
UHO\Mag?wF?[SgSgISE_wsFBO[@QF|G~?dB{hFw?
UHO\M?geAC_lsGEQ?]C`Op?WdI?Ckp?NaWCcOk?W

The computation took 143 hours for 22 vertices, about 2/3 of which was generating the graphs.

That's 114,000 graphs per second.

For 23 vertices, the estimate is about 4000 hours, so I won't do it.

Brendan.

On Sun, Oct 12, 2025 at 8:11 AM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Update: a(18) is indeed 12 according to my calculations

Elijah

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD-2a7F6-pKek%2BW0iXvFXHGJr5gUg%2BuT66JDZB0zdfbbtSDndA%40mail.gmail.com.

[Allan Wechsler]

I haven't been following this carefully enough, but I have a couple of dumb questions.

1. Is a(n) obviously non-decreasing? I guess it must be, because you can create a graph that needs at least a(n-1) cuts by just adding an extra edge involving the new vertex to one of the worst cases on n vertices. But I might have misunderstood something.

2. Is the algorithm easily parallelizable? It's possible that we could learn a few more values with just a few minutes on some server farm, if some organization got interested and was willing to donate the CPU time. Or we could just buy the computation from Google or AWS.

3. It sounded as if Brendan might have a more dramatic speedup that would render an astronomic proportion of the computation irrelevant, by focusing on a few critical graphs. Did I misunderstand that? Have we already wrung all the available advantage from Brendan's insight?

It's exciting to read threads like this!

-- Allan

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJeNNUgf%3DdjqYzpPJdLh6bkkNH7skLH0_Zsn-Defc82B6vp9KA%40mail.gmail.com.

[Brendan]

1.  Yes, it is obviously non-decreasing.  If you have a triangle-free graph on n vertices that needs the removal of a(n) edges to make it bipartite, then you can add one vertex to make a graph on n+1 vertices that also needs a(n) edges.

2.  Yes, it is parallelizable, but the combinatorial explosion still strikes.  a(23) would take about 4000 hours and a(24) might take as long as 20 years.  Dividing it into small pieces to run in parallel is routine but all the pieces need to be run.  Note that more than half of the time is used in making the graphs, so there is only a small gain possible by speeding up the testing.

3.  I tested all the graphs, first with a fast heuristic that eliminated all but a handful, then with a slower exact search.

Unless someone can spare 4000 cpu-hours, the only hope of going further would be an insight into which type of graph is extremal in this sense, so that not all maximal-triangle-free graphs need testing.

Brendan.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CADy-sGEgWo4Rem%3DhmWXgFHub6KXGR2tkB4PeBqijTeVMxxL_DQ%40mail.gmail.com.

[Brendan]

Is this a correct summary?  I'm picking numbers out of various postings and could make mistakes.

n    a(n)

1    0

2    0

3    0

4    0

5    1

6    1

7    1

8    2

9    2

10   4

11   4

12   5

13   6

14   7

15   9

16   9

17  10

18  12

19  13

20  16

21  16

22  17

I plan to make all the extremal graphs available.  Brendan.

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD-2a7GMYt7E0yCe7uHS7wCLqedfJ2wMMHy7gUW7f8yKxrBuDQ%40mail.gmail.com.

[Brendan]

Here is the table again with the number of extremal graphs.  I'm including all

graphs and not only those which are maximal triangle-free.  The extras can

be found from the maximal triangle-free graphs by removing edges.

n   a(n)   graphs

1    0       1

2    0       2

3    0       3

4    0       7

5    1       1

6    1       3

7    1      19

8    2       7

9    2      86

10   4       1

11   4      14

12   5       2

13   6       8

14   7       1

15   9       1

16   9      34

17  10      44

18  12       7

19  13       5

20  16       1

21  16      85

22  17    1076

Brendan.

[Neil Sloane]

Will somebody (Brendan, perhaps) please add those 2 sequences to the OEIS?

That will then help everyone keep track of all the updates.

This thread is already almost unmanageable!

Best regards

Neil 

Neil J. A. Sloane, Chairman, OEIS Foundation.

Also Visiting Scientist, Math. Dept., Rutgers University, 

Email: njas...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJeNNUgDpRovnjrBAbJ8rynYdYAVDJnepUtNLYX4WzjksOG6pA%40mail.gmail.com.

[Brendan]

Hi Neil,

I started on A387956 and A387957.

But first, I'm running the next (last!!) case and will put the extremal graphs on my web page so that I can cite them.

Cheers, Brendan.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAAOnSgQCaJoxL93kgSYFOGxe_WDe8NNWpKeAfif33BXhXwFS9A%40mail.gmail.com.

[Elijah Beregovsky]

Wait, I’ve already started the sequences! They’re A389646 and A387954. Please, join in, don’t create the duplicates!

Elijah

[Brendan]

I don't see how to delete  A387956 and A387957, can someone do it please?

On Sun, Oct 12, 2025 at 11:43 PM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Wait, I’ve already started the sequences! They’re A389646 and A387954. Please, join in, don’t create the duplicates!

Elijah

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/E50D5307-647C-4939-AAD3-2F3D7FFD3168%40gmail.com.

[Martin Fuller]

a(n) <= a(n-1) + n/5.

Proof: Every triangle-free graph that is not bipartite has a vertex of degree <= 2n/5 [1] [2].

Let x be such a vertex. G\x can be made bipartite by removing a(n-1) edges. And x can be added to this colouring by removing at most d(x)/2 edges incident on x.

Does this give a better method to find a(23)? Generate all maximal triangle-free graphs on 22 vertices with a(G) >= 14, then extend only these graphs to 23 vertices.

Martin Fuller

[1] Triangle-free graph - Wikipedia

[2] Andrásfai, B.; Erdős, P.; Sós, V. T. (1974), "On the connection between chromatic number, maximal clique and minimal degree of a graph" (PDF), Discrete Mathematics, 8 (3): 205–218, doi:10.1016/0012-365X(74)90133-2.

[Sean A. Irvine]

Done.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJeNNUhSPiADk2MMy7wVJAhkM30H0USb2%2ByJ3n42kwGyFb0HkQ%40mail.gmail.com.

[Daniel Mondot]

re: a(n) <= a(n-1) + n/5.

Empirically, from the numbers already found, it looks like :

 a(n) <= a(n-1) + 1 + n/10   (no proof).

To view this discussion visit https://groups.google.com/d/msgid/seqfan/b7f1e8a2-5ebb-464e-bdfd-c95ae14271cbn%40googlegroups.com.

[Brendan]

Hi Martin,

I don't know of a reason why a maximal triangle-free graph on 23 vertices should contain a maximal triangle-free graph on 22 vertices.

However, with the additional step of removing edges while a(G)>=14 it is indeed a plausible approach.

Brendan.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/b7f1e8a2-5ebb-464e-bdfd-c95ae14271cbn%40googlegroups.com.

[Neil Sloane]

Brendan,  You should be able to edit your two sequences yourself.

Open Edit, delete lines, click Save

Best regards

Neil 

Neil J. A. Sloane, Chairman, OEIS Foundation.

Also Visiting Scientist, Math. Dept., Rutgers University, 

Email: njas...@gmail.com

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJeNNUhSPiADk2MMy7wVJAhkM30H0USb2%2ByJ3n42kwGyFb0HkQ%40mail.gmail.com.

[Victor Miller]

I'd like to put in a plug for MaxSat solvers. I used the MaxSat solver RC2 (using its interface from python using the package python-sat). It was able to complete the calculation for a(17) in under 2 minutes on my M3 mac.

On Sat, Oct 11, 2025 at 1:09 AM Elijah Beregovsky <elijah.b...@gmail.com> wrote:

Translated the problem into SAT, basically the same as with MILP, except I added an explicit XOR(e,v,w)==true constraint (note, that it inverts e, and turns this into a minimization problem). And then I switched the problem from an optimization to constraint satisfaction, as Doug suggested — instead of minimizing sum(e) I now added the constraint sum(e) <= current worst cut. We don’t need to know the very best cut, we just need to know a certain number of edges is enough. It sped up the calculation by an order of magnitude, thanks, Doug! Now a(18) is running, and I project that it’ll take ~13 hours in total. Current bound after 1 hour is a(18) >= 11

Elijah

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/A0489B28-268B-4B35-98C9-09D6DC1EE30D%40gmail.com.