MatroidSet

[Gordon]

Hi All

I think that for working with collections of matroids, we need to prioritise the development of a MatroidSet class, similar to the rudimentary one developed by Rudi.

To avoid duplication of effort however, I think we should decide what the interface should be and then assign a volunteer to code it, rather than each of us writing our own slightly different version at the same time.

We should also make sure it implements the proper magic methods so that it works as expected with normal Python constructs (such as "in") and so on. (Here's a link describing the magic methods for container-type classes http://www.rafekettler.com/magicmethods.html#sequence ).

I'd like to be able to do the following things

- keep a list of matroids up to isomorphism (if we were fancier, we could create a class that accepted an optional function as an argument and used that function wherever the default class uses is_isomorphic)

- test membership ("in" and "not in")

- add and delete matroids

- list them all

There may be other things that other people would like?

[Stefan van Zwam]

Hi all,

First of all, I think MatroidCollection might be a better name than MatroidSet. I'd propose a hierarchy:

Abstract MatroidCollection - just has a membership test.

Then subclasses like MinorClosedCollection, ThreeConnectedMatroids, BinaryMatroids, ...

The relevant classes should have methods for extending/coextending, caching the membership results, accessing stored databases ... if we got really fancy, we'd allow intersections. Then there would be two methods:

* extend
* extend_filter

The intersection class (MatroidCollectionIntersection???) would call the extend() method of one of the members, and then filter the results for each remaining member.

For now I'm focussing on getting the current code accepted into Sage (it looks like they're pretty positive, though we have not yet gotten a "positive review"). And a ton of other stuff, so I don't think I'll be able to contribute much until La Vacquerie.

Cheers,

Stefan.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "sage-matroid" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-matroid...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Rudi Pendavingh]

It will take some time and planning before we have such a nice class hierarchy as Stefan suggests.

I think that Gordon wanted something more modest for now, just a class that holds set of matroids up to isomorphism, with a convenient interface. Something that behaves like a Python set of matroids, but using matroid isomorphism rather then matroid equality to identify members.

Python does not allow you to throw in your own notion of equivalence by giving options to set(), like C++. The equivalence used is fixed by the objects in the set.

So another option is to create a Python class that represents a matroid isomorphism class [M_0]:={M | M isomorphic to M_0}, and which is created from one representative M_0. Then we only need to write the necessary equivalence testing methods in that class that makes it possible to construct a Python set of these objects.

--Rudi

[Gordon Royle]

Yes, Rudi is correct. I'm just after the low-level structure that maintains a set of matroids and adheres to Python conventions for sets, allowing reasonably quick membership testing etc.

Any of the classes of the nature that Stefan is suggesting will need to store a set (or collection) of matroids SOMEWHERE, along with additional logic to ensure that the given collection meets the requirements of the class.

In my opinion, composition is much more suitable than inheritance in this situation - in other words, Stefan's MinorClosedCollection would USE a low-level MatroidSet object, rather than EXTEND the MatroidSet class.

It's a bit like saying that a Polygon should contain "an array of 2D points" and a set of methods determining things like whether a given point is inside the Polygon, and other specialised "polygon logic". I wouldn't make a Polygon a _sub-class_ of an "array of 2D points" but rather just make a Polygon _contain_ an array of 2D point.

Cheers

Gordon