This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

It may be more useful to first create a function that takes a graph6 string (not a file) as input and creates a graph from it. Permission was granted (in private) to re-use code from gtools/nauty for this. (The license is not GPL2-compatible, so we could not just rely on that.)

I use both nauty and igraph, and I think that implementing nauty's graph formats (graph6, sparse6, and digraph6) in igraph would be helpful. I find the graph6 format particularly convenient since it compactly encodes simple graphs as strings of ASCII characters. If such functionality were implemented in igraph, would it make more sense to work with C-style strings or igraph vectors of chars?

Reading nauty strings (graph6/digraph6/sparse6, but not incremental sparse6) is already implemented in the Mathematica interface of igraph. It just needs to be ported over to C. It's not that hard to do but I was going to wait until writing nauty string is also implemented. Would the one-way conversion already be useful to you @tjsavitsky? If yes, we can make it happen for igraph 0.9.

Yes, being able to read the nauty formats would be helpful. Thanks!

OK, time allowing I'll port over the implementation I did for IGraph/M. It should be easy.

May I ask which language you use igraph from? (C, R, Python, Mathematica?)

@tjsavitsky If you have the expertise and the time to contribute a function to convert an igraph_t to a graph6/digraph6/sparse6 string, that would be very much appreciated. If you decide to give it a try, let me know in advance. I'll be happy to give some guidance. Note that we have permission to re-use code from nauty that deals with reading/writing these formats (only for these parts!).

The format description is here:

https://users.cecs.anu.edu.au/~bdm/data/formats.html

https://users.cecs.anu.edu.au/~bdm/data/formats.txt

sparse6 in particular seems to be a bit fussy to deal with, so re-using nauty's original code is not a bad idea. It would reduce the likelihood of bugs.

As for the reverse conversion (nauty -> igraph), that's mostly done, so we don't need help with it.

If such functionality were implemented in igraph, would it make more sense to work with C-style strings or igraph vectors of chars?

I would say C style strings.

All uses of igraph_vector_char_t that I could find are numeric (not for storing text).

@ntamas @gaborcsardi Do the R/Python interfaces give us any reason to choose igraph_vector_char_t over char *? (I don't expect so.)

Nope, just go with C strings; Python can convert from a Python string to a C string but not to an igraph_vector_char_t.

In the Python version of igraph, has the conversion of graph6 been implemented?

No, it's not even in the C core.

It's a work in progress, see #2526