Idea: Add SubGraph data type

[snowleopard]

Idea: Add SubGraph data type

[nobrakal]

@snowleopard Oops, sorry for this, I copied/pasted my comment is the wrong issue, I just deleted it (here it was totally without sense :p ) and moved to the right issue !

[snowleopard]

Interesting. I haven't though about exactly your version of SubGraph, but I was exploring ideas of extending the Graph datatype (in a different module) with some higher-level combinators. For example:

data Graph a where
    Empty   :: Graph a
    Vertex  :: a -> Graph a
    Overlay :: Graph a -> Graph a -> Graph a
    Connect :: Graph a -> Graph a -> Graph a
    Fmap    :: (a -> b) -> Graph a -> Graph b
    Bind    :: (a -> Graph b) -> Graph a -> Graph b
    ...

This also allows some efficient algorithms.

My initial impression is that your SubGraph will end up containing too many constructors making it quite painful to write algorithms that can efficiently manipulate such graphs... But I may be wrong.

I'd like to explore this direction.

The Graph data type could be made strict

I think we could simply have a strict version of this type, e.g. Algebra.Graph.Strict. I'd like to keep the default implementation lazy, as it's more idiomatic Haskell.

Some algorithms could benefit from this, since it gives a direct representation to some induced subgraphs.

Can you give a specific example?

In combination with modular decomposition this would be extremely useful.

Yes, that would be great!

[anfelor]

with some higher-level combinators.

Absolutely, but why should they be in Graph? An algorithm working on graphs would have to consider all of them and there would be no expand function to eliminate them from the algebra. To me they sound like a perfect fit for a SubGraph type.

your SubGraph will end up containing too many constructors

That is true, but the algorithm doesn't need to consider all constructors, just call expand and use the normal algebra of graphs!

I think we could simply have a strict version of this type, e.g. Algebra.Graph.Strict.

Sounds good!

Can you give a specific example?

Only trivial examples so far where we could get constant instead of linear time; topSort just using the list of a Clique instead of considering all the unnecessary edges. The speedup probably wouldn't justify the additional boilerplate so I have to admit it's closer to an idea than a proposal at the moment.

[snowleopard]

Absolutely, but why should they be in Graph? An algorithm working on graphs would have to consider all of them and there would be no expand function to eliminate them from the algebra. To me they sound like a perfect fit for a SubGraph type.

Right, I see what you mean. Perhaps, this could indeed be useful, but I also can't come up with convincing examples. The topSort on Clique speed-up can be achieved in many other ways.

The speedup probably wouldn't justify the additional boilerplate so I have to admit it's closer to an idea than a proposal at the moment.

Let's keep this issue open. Perhaps, we'll come up with a good use for the SubGraph datatype.

[snowleopard]

@nobrakal Thanks! I didn't really explain what I meant by experiments: I meant to measure performance of graph consumption algorithms: if they take longer, it means some extra work was needed. So you should pick the NFData instance which leads to fastest graph deconstruction.