[PartitionedGraphs] Rename various types and functions to improve clarity.

[jack-dunham]

This PR renames some types and functions in the PartitionedGraphs library for clarity. Specifically:

• PartitionsGraphView -> QuotientGraph.
• PartitionVertex -> SuperVertex.
• PartitionEdge -> SuperEdge.

The associated functions pertaining to these types have also been renamed accordingly. I have also attempted to rename local variables to reflect this change.

Tests have been updated, and by some miracle, all passed first time.

[jack-dunham]

Considering this is technically a breaking change I've opted to increment the minor version number.

[mtfishman]

Thanks @jack-dunham, I think these names are clearer. @JoeyT1994 let us know what you think of these changes, I think we've discussed these name changes.

@jack-dunham when you make breaking changes you need to bump the subdirectory Project.toml compat entries accordingly (i.e. docs/Project.toml, examples/Project.toml, test/Project.toml). It's a bit annoying, ideally we wouldn't have to specify the compat entries of the package itself in those subdirectories but we have to right now because of limitations of CompatHelper.

[JoeyT1994]

Yeah I like these name changes -> they are more intuitive and quotient graph is in-line with the definition from the graph-theory community.

[mtfishman]

@jack-dunham @JoeyT1994 I'll merge this so we can start using it in ITensorNetworksNext.jl. ITensorNetworks.jl and TensorNetworkQuantumSimulator.jl will need to be upgraded but that should be pretty easy since it is just a name change.

[mtfishman]

This is a slight nitpick, but could you rename this to quotientgraph? My reasoning is that generally this will construct a QuotientGraph, so we can think of it as the lowercase function version of QuotientGraph.

In fact to simplify things right now maybe we could just use QuotientGraph directly and get rid of the function version... I think we introduced that function since PartitionsGraphView was a long name to write out, but QuotientGraph is easy to write. @jack-dunham @JoeyT1994 curious to hear your thoughts on that (best to decide now while we are making a breaking change...).

[jack-dunham]

I think the function is unnecessary especially as QuotientGraph is intended a wrapper type. I also think using the constructor directly is clearer.

[mtfishman]

Ok, let's go with that, we can always add a function back if needed.

[jack-dunham]

I had to add a (very simple) inner constructor to avoid recursion, so now QuotientGraph must wrap an AbstractPartitionedGraph. Passing an AbstractGraph that does not subtype AbstractPartitionedGraph still passes the trivial partition of this graph to QuotientGraph, as before.

All tests pass on my end.

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[jack-dunham]

Perhaps we want:

Suggested change

	struct QuotientGraph{V, G <: AbstractGraph{V}} <: AbstractNamedGraph{V}
	struct QuotientGraph{V, G <: AbstractPartitionedGraph{V}} <: AbstractNamedGraph{V}

to make this even more explicit?

[mtfishman]

I think that relates to our discussion around representing a partitioned tensor network, i.e. a type can act like a partitioned graph without explicitly being an AbstractPartitionedGraph subtype, as long as it overloads a minimal interface of functionality related to how the graph is partitioned. So I think it is better to keep it more general and think of it more as an interface requirement.

[jack-dunham]

Okay, in that case we need to define that interface. I suggest we remove the method:

QuotientGraph(g::AbstractGraph) = QuotientGraph(PartitionedGraph(g, [vertices(g)]))

It doesn't seem required for any tests to pass, and define a new function partitions_graph:

partitions_graph(g::PartitionedGraph) = pg.partitions_graph

So a TensorNetwork with underlying_graph of type PartitionedGraph needs to define a method for partitions_graph, i.e.

partitions_graph(tn::TensorNetwork) = partitions_graph(underlying_graph(tn))

Perhaps this can be defined on AbstractDataGraph? Although I feel like that is getting a little cumbersome. Perhaps it is best to just make the choice to wrap TensorNetwork in PartitionedGraph for now? That way one can just repeatedly define more and more layers of partitioning, including partitioning the quotient graphs of any of these partitions, with the tensor network data always sitting at the base of this.