This post is another installment in my series on matroid computation in SageMath [1], with older posts here, here, here, and here. As always, clicking the “**Evaluate**” buttons below will execute the code and return the answer (or, in today’s post, draw the picture). The various computations are linked, so execute them in the right order.

Last summer, Jayant Apte was selected to participate in the Google Summer of Code program. During the summer he extended SageMath’s matroid capabilities in two major ways.

- Drawing geometric representations of rank-3 matroids
- A more efficient minor test for binary matroids

The first of these has been part of Sage for a while; the second is awaiting review but should be included fairly soon.

Let’s get started with everyone’s favorite matroid.

That was easy! We can deal with parallel elements too:

Loops are no problem either:

Note that we resort to a slightly different method of display for large parallel classes. The point in the geometric representation will receive a label that is not an element of the matroid, and below the diagram it will state that this label actually represents a parallel class of elements.

The examples above were chosen because the default positioning algorithm gives a decent picture. Unfortunately, that is not always the case:

In these instances, the options of the `show()`

method come in handy. To get a full list, type `M.show?`

in your own session of SageMath, and hit the

This is not bad, but we don’t need a curved line to draw this diagram. The solution is to specify a different basis, whose elements will be placed at the corners of a triangle:

Trying different bases is not going to help the Pappus matroid too much. In that case, after inspecting, for instance, `M.circuit_closures()`

, we can come up with custom coordinates for the points. To tell Sage that we’re doing this, we add the option `pos_method=1`

.

A second example, just because:

Our final option today deals with *betweenness*. In projective geometry this is a meaningless concept, of course, but in a concrete diagram it can matter whether we draw a line from $a$ through $b$ to $c$ or from $b$ through $a$ to $c$. In SageMath, we can specify this through the `line_orders`

option. An example should make this clear.

We specify the order on the line $\{d,e,f\}$:

A slightly less contrived example is provided by $\textrm{AG}(2,3)$.

I prefer a rotational symmetry to the curved lines:

It’s not perfect (I’d like the curved lines to protrude out of the square), but it’s in the ballpark.

Note: after you have drawn a matroid, the options for drawing so are saved. So next time,

will produce the same graphic.

There are many ways in which the drawing routines can be improved. Options like color, aspect ratio, letting the user decide how to handle parallel elements, and functionality like saving plot information when you save a matroid, adding “nice” plots to the built-in library of matroids, special plots for Dowling geometries, plots for rank-4 matroids, and the list goes on. Interested? There’s another Google Summer of Code coming up soon!

[1] SageMath is now the official name of the Sage Mathematical Software System.