## Getting started with sage_matroids IV

Over at the MatroidUnion, Irene has written a comprehensive series of posts on classes of matroids that arise from biased graphs, so head there for more details on how even cycle matroids fit into the grand scheme of things. In this post however, we’ll just think about even cycle matroids on their own. This is also the first post I’ve written in Markdown, rather than battling with the visual editor, and while it formats the code nicely, I can’t make it format the *output* nicely (without the line numbers etc).

It is often convenient to identify a binary matroid with the *row space* of any (and hence all) of its representing matrices. For example, we’ve already discussed *graphic matroids* which are the binary matroids that can be represented by the vertex-edge incidence matrix of a graph, and so we’ll just call a subspace *graphic* if it is the row space of such a matrix. An *even cycle* matroid is a binary matroid that can be represented by the vertex-edge incidence matrix of a graph with an extra row added or, equivalently, a binary vector space containing a *graphic subspace* of codimension one.

There is no fast algorithm known for checking if a binary matroid is an even cycle matroid and so we have to just check all of its subspaces of codimension one for being graphic. It is easy to see that all the subspaces of codimension one can be obtained from a matroid M by *extending* M by a binary element e not in M and then immediately *contracting* e and so we get the following function:

def is_evencycle(m): if (m.rank() < 4): return true else: return any([n.contract('X').is_graphic() for n in m.linear_extensions('X')])

This uses the name ‘X’ to label the new element that is immediately contracted. If one of the elements of m is already called ‘X’, then the linear extensions method will fail. A more careful approach would be to first find a *definitely* new label.

Even-cycle matroids form a minor-closed class and so a very natural problem is the determination of the excluded minors for this class. We’ll certainly need to able to *check* that a matroid is an excluded minor – recall that this means that the matroid is not *itself* an even cycle matroid, but all of its single element deletions and contractions are even cycle matroids. We can easily modify the code that we used for graphic matroids to get:

def is_excludedminor_evencycle(m): return (not is_evencycle(m) and all([is_evencycle(m.contract(x)) for x in m.groundset()]) and all([is_evencycle(m.delete(x)) for x in m.groundset()]))

Let’s use this to find the excluded minors for even cycle matroids of rank at most 5 in the most naive fashion possible, in other words, simply applying the function to every one of the 1372 binary matroids of rank at most 5. Assume that an array called “rank5s” has been defined such that “rank5s[e]” contains all the e-element binary matroids of rank at most 5. (It is fairly easy to make such an array using Sage.)

exminors = [] for e in range(32): for m in rank5s[e]: if is_excludedminor_evencycle(m): exminors.append(m)

What do we get at the end of this?

sage: len(exminors) 13 sage: [ [m.rank(),m.size()] for m in exminors] [[5, 12], [5, 12], [5, 13], [5, 13], [5, 13], [5, 13], [4, 14], [5, 14], [5, 14], [5, 14], [5, 14], [5, 15], [5, 15]]

There is a unique excluded minor of size 14 and rank 4, which can only be , the

matroid obtained by deleting an arbitrary element from , but the 12 additional excluded minors of rank 5 do not bode well for an excluded minor characterisation of even cycle matroids.

In fact, we’ll see in a later post in this series that things are even worse than it seems, but let’s return to the main point of this post, which is to demonstrate the relative ease of building on the functions provided in sage-matroids.

One fundamentally unsatisfying aspect of this code for excluded minors is that we’ve written two almost identical functions for the “excluded minor” functionality, but changing the occurrences of

m.is_graphic()

to

is_evencycle(m)

and if we continue to work with more properties, then we’ll need a separate function for

each and every property.

There is, however, a better way — we can create a function so that the property to

be tested is one of the *parameters* of the function.

def is_excluded_minor(p,m): return ( not p(m) and all([p(n) for n in [m.contract(e) for e in m.groundset()]]) and all([p(n) for n in [m.delete(e) for e in m.groundset()]]))

Now we can simply test whether a matroid is an excluded minor for the class of even cycle

matroids with

is_excluded_minor(is_evencycle, m)

and if we subsequently write a function for testing some other property, say whether the

matroid is an *even cut* matroid, then we can just insert the new property name into the

same function.

is_excluded_minor(is_evencut, m)

The only minor wrinkle is to remember to use the right name for the built-in functions.

is_excluded_minor(BinaryMatroid.is_graphic, m)

Next time, we’ll look a little more closely at the excluded minors for the even cycle matroids

and try to work out just how bad things might get!

## Getting started with sage_matroids: III

After being busy for the last couple of months, it’s time to return to learning how to use a few more of the basic features of sage_matroids.

Last time we looked at *graphic matroids* which are the binary matroids that can be represented by the vertex-edge incidence matrix of a graph, and mentioned that sage_matroids has a very effective test for being graphic.

```
sage: f7 = matroids.named_matroids.Fano()
sage: k5 = BinaryMatroid(graphs.CompleteGraph(5).incidence_matrix())
sage: f7.is_graphic()
False
sage: k5.is_graphic()
True
```

So the Fano plane is not graphic, while the cycle matroid of is graphic. Now if a matroid is graphic then all of its *minors* are graphic, where a minor is any matroid obtained by repeatedly contracting and deleting elements. For example, let’s just confirm this by checking all the contractions of . We’ll do it in two steps first.

```
sage: k5cons = [k5.contract(x) for x in k5.groundset()]
sage: [n.is_graphic() for n in k5cons]
[True, True, True, True, True, True, True, True, True, True]
```

We can shortcircuit this to avoid making the intermediate list of minors explicitly.

```
sage: [k5.contract(x).is_graphic() for x in k5.groundset()]
[True, True, True, True, True, True, True, True, True, True]
```

If we just want to check that all the values are True without listing them all, we can use the handy Python construct all which is True if all of the elements of an iterable are True.

```
sage: all([k5.contract(x).is_graphic() for x in k5.groundset()])
True
```

Now, what about the Fano plane?

```
sage: all([f7.contract(x).is_graphic() for x in f7.groundset()])
True
sage: all([f7.delete(x).is_graphic() for x in f7.groundset()])
True
```

So *also* has this property, so although it is *not* graphic itself, all of its *minors* are graphic, and so it is a *minor minimal non-graphic* matroid or, in other words, an *excluded minor* for the class of graphic matroids.

One of the fundamental observations of matroid theory is that any minor-closed class of matroids can be characterised by listing its excluded minors, and there is a vast literature that either (1) takes a natural property defining a minor-closed class of matroids and *finds* the excluded minors, or (2) takes a list of matroids and investigates the properties enjoyed (endured?) by the class of matroids without minors in the initial list.

So, let’s write a *function* to detect when a binary matroid is an excluded minor for the class of graphic matroids. This is true when the matroid passed in as the argument to the function is not graphic itself, but all of its single element deletions and contractions are graphic.

```
sage: def is_excludedminor_graphic(m):
return (not m.is_graphic()
and all([m.contract(x).is_graphic() for x in m.groundset()])
and all([m.delete(x).is_graphic() for x in m.groundset()]))
```

This code defines a function that can now be called by name for the rest of the Sage session; if it proves useful, then the code can be saved in a file and “imported” at the beginning of a future Sage session.

```
sage: is_excludedminor_graphic(f7)
True
```

So what are some other excluded minors for graphic matroids? It turns out that — the dual of the Fano matroid — is another one, as we can confirm.

```
sage: is_excludedminor_graphic(f7.dual())
True
```

Of course, the full list of excluded minors for graphic matroids is known, and consists of , and the duals of the graphic matroids and . Let’s just check the first of these.

```
sage: is_excludedminor_graphic(k5.dual())
True
```

It is a famous result of Robertson and Seymour that every minor-closed family of graphs has a *finite* list of excluded minors and Geelen, Gerards and Whittle have shown that the same is true for binary matroids. Of course, finite doesn’t mean *short* or *easy-to-find* and there are lots of minor-closed classes for which the list of excluded minors is not known at all, or for which the list of known excluded minors is vast and still growing.

Next time we’ll talk more about excluded minors for some classes of binary matroids.

## The Open Problem Garden

It is nearly time for our third “research retreat” where our research group goes away for a few days and sit down in various combinations to discuss some new research problems, preferably problems that require some combination of all our specializations, skills and interests. The aim is to broaden our joint knowledge, introduce graduate students to problems outside their thesis (at least for a little while), encourage additional collaborations, and of course just to have a nice time away from the daily routine.

Choosing suitable problems is hard of course, because anything too technical or specialized immediately makes it difficult for someone outside the immediate area to get up to speed. On the other hand, combinatorics is renowned for easy-to-state problems that are impossible to solve, so we want to avoid those as well.

So before each retreat, I find myself looking online for “open problems in combinatorics” and finding various lists of problems, such as Peter Cameron’s list, Douglas West’s list, and of course “The Open Problem Garden“, which was set up by Matt DeVos and Robert Samal to be a “crowd-sourced” list of problems where users could add problems, comment on problems, discuss solutions etc.

Even though everything on the site seems to work well technically (it is based on the notoriously massive and hard-to-learn Drupal CMS so I can only imagine how hard it was to get working), it simply doesn’t seem to have taken off, and I can’t really understand why. A good fraction of the problems were posted by Matt and Robert, and though I’ve added a few and tried to comment on others, the lack of activity from other people means that it rapidly dropped off my radar.

On the other hand, MathOverflow seems to work brilliantly and have created a real sense of community, but again I have no real idea why. On the other hand, when I first heard about Twitter, I thought it was the dumbest idea I’d ever heard, so my insight into what works and doesn’t is clearly not very finely tuned.

It would be really nice if something like the Open Problem Garden worked well, but what is the secret sauce it needs to take off? Could it really just be the gamification that MO has, complete with upvoting, downvoting, points and “medals”? Or something more sophisticated?

## 100 today

I don’t usually post personal things on this maths blog, but today I’ll make an exception.

My father was born in Perth on 17 January 1914, which makes him 100 years old today (and still going strong). He’s had a pretty full life, and is mildly famous for his participation in The Great Escape, of which there are now only two survivors (the other being a sprightly 92-year old from Devon, UK).

Happy Birthday Dad!

## Regular cycles of elements in finite primitive permutation groups

Cheryl Praeger, Pablo Spiga and I have just uploaded to the arxiv our preprint Finite primitive permutation groups and regular cycles of their elements. Everyone recalls from their first course in group theory that if you write a permutation in cycle notation, for example *(1,2)(3,4,5)(6,7,8,9,10), *then its order is the lowest common multiple of it cycle lengths. As I have just demonstrated, not every permutation must have a cycle whose length is the same as the order of the element. We call a cycle of an element* g* whose length is the order of *g*, a *regular cycle*. A natural question to ask is when can you guarantee that a permutation has a regular cycle? Or in particular, for which permutation groups do all elements have a regular cycle?

Clearly, the full symmetric group contains elements with no regular cycles, but what about other groups? Siemons and Zalesskii showed that for any group *G* between PSL(n,q) and PGL(n,q) other than for (n,q)=(2,2) or (2,3), then in any action of *G*, every element of *G* has a regular cycle, except G=PSL(4,2) acting on 8 points. The exceptions are due to isomorphisms with the symmetric or alternating groups. They also later showed that for any finite simple group *G*,other than the alternating group, that admits a 2-transitive action, in any action of* G* every element has a regular cycle. This was later extended by Emmett and Zalesskii to any finite simple classical group not isomorphic to PSL(n,q).

With these results in mind, we started investigating elements in primitive permutation groups. The results of this work are in the preprint. First we prove that for , every element of Sym(m) in its action on *k*-sets has a regular cycle if and only if *m* is less than the sum of the first *k+1* primes. After further computation we were then willing to make the following conjecture:

Conjecture: Let be primitive such that some element has no regular cycle. Then there exist integers and such that

Gpreserves a product structure on with , and , where Sym(m) induces itsk-set action on .

The general philosophy behind why such a result should be true is that most primitive groups are known to be small in terms of a function of the degree. There is a large body of work bounding the orders of primitive permutation groups with the best results due to Maroti. The actions of Sym(m) on *k*-sets are the usual exceptions.

Our paper goes about attempting to prove this conjecture. We make substantial progress and reduced its proof to having to deal with all the primitive actions of classical groups. Note that Emmett and Zalesskii only dealt with simple ones. One consequence of our work is we showed that every automorphism of a finite simple group has a regular cycle in its action on the simple group.

Pablo and Simon Guest have subsequently gone on to prove the result for all actions of classical groups and so the conjecture is now a theorem.

Pablo gave a great talk about the conjecture and its subsequent proof at the recent BIRS workshop on Permutation Groups in Banff which you can view here.

## Congratulations!

The Minister for Education (finally) announced the ARC Future Fellowships commencing in 2013 this morning, and simultaneously, the DECRA’s and Discovery Projects. Our research group missed out on a grant of the first and second kind, but we had success with two Discovery Projects:

- Cheryl Praeger, Stephen Glasby, and Alice Niemeyer (“Finite linearly representable geometries & symmetries).
- Gordon (“Real chromatic roots of graphs & matroids”)

I remember last summer when both grant applications were being written, and it was a lot of work for all involved, so it’s great to see that both have awarded to support cutting edge research.

## Getting started with sage_matroids: II

Following on from my previous post on getting started with sage_matroids, let’s look at a few more of the built-in features.

One of the most fundamental classes of matroids is the class of ** graphic matroids**. Given a graph , the graphic matroid has the edge set of as its elements, and the forests of as its independent sets. The circuits of , i.e. the minimal dependent sets, are then precisely the cycles of , so sometimes is called the

*of .*

**cycle matroid**The decision to go with Sage, rather than to either develop a stand-alone system or build on an existing stand-alone system, was largely driven by the fact that Sage provides both a standard programming language and a vast amount of inbuilt combinatorial functionality already. In particular, we can just piggyback on the very extensive “graphs” package to immediately create a graphic matroid using, of course, the canonical graph theory example.

sage: pm = Matroid(graphs.PetersenGraph()) sage: pm Regular matroid of rank 9 on 15 elements with 2000 bases