Try using NautyTracesInterface as an alternative to bliss

[sebasguts]

It would be nice to have different AutomorphismGroup algorithms play against each other. The NautyTracesInterface package aims to provide a C-level-link to nauty and traces.

It would be nice to have digraphs work with this, to see how the different algorithms work with each other.

[james-d-mitchell]

I'd like to do this.

What do you envision? Some sort of global variable or whatever that specifies whether to use bliss or nauty? Or a per digraph option, or what?

Or multithreaded code that actually runs both bliss and nauty and uses which ever one returns the answer faster?

I don't think doing any of these will be all that hard, but I'd like to know what you think before starting @sebasguts @wilfwilson ?

[sebasguts]

I think all of this :)

First, one could have a global switch indicating which should be used if nothing is specified: bliss, nauty, or traces.

Then, additionally, it might be useful to be able to set it per digraph.

Last, it would be cool if one could use all three in parallel, seeing what finishes first, and discard the other computations.

[wilfwilson]

It would be nice to not rely on bliss, since it does not seem to be actively developed, whereas nauty/traces is. So even for that reason it would be nice to have this in place.

Personally, I've never been bothered by the performance of bliss, so I'm not really sure what I would find the most useful. All of your suggestions seem natural @james-d-mitchell.

Having a per-digraph option would be nice. Perhaps that would require some sort of options record like you use for semigroups (which we use to specify "acting/non-acting", for instance), and the default options record would specify the default behaviour.

I think the most important discussion would be: what is the default?