Re: [boost] [BGL] isomorphism, filtered_graph problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-11-14 11:28:05

On Tuesday 06 November 2001 21:05, you wrote:

> ghost> >
> ghost> > As per the docs, the second graph has to be a BidirectionalGraph,
> so ghost> > you need to use bidirectionS instead of directedS
> ghost>
> ghost> I've missed that. But... is this requirement present due to
> ghost> the algorithm used or for some other reason. The graphs
> ghost> which I'd like to compare are directed by definition.
>
> The algorithm uses the in_edges() function, so it needs bidirectional. The
> boost adjacency_list "bidirectional" graph is a directed graph.
Okay, will use it. Is in_edges() required for all exising isomorphism 
algorithms (just curious)? 

> ghost> > jsiek> Yes, I thought about this. I don't think the semantics can
> ghost> > jsiek> change, though I will document them.
> ghost> > jsiek>
> ghost> > jsiek> We certainly do need a resizable-on-subscript container.
> Would you ghost> > jsiek> be interested in writing one?
> ghost>
> ghost> Alas, I don't have quite enough time to promise writing one.
> ghost> For now, we can at least discuss what precisely type of
> ghost> container it should be. In particular, should iteration be
> ghost> supported? GTL's node map does not support in, IIRC, and
> ghost> supporting it would require skipping elements while
> ghost> iterating.
>
> Well, I think it would be enough to just support the mapping. 
A, that would be quite easy. See attachment for my first try.

> It would not
> need to fulfill any of the requirements for a Container. 
In fact, if I read SGI STL docs right, there are almost no requirements it 
can fulfill.
> It would fulfill the requirements of a property map.
I've made an attempt do so. Half successfull. The problem is that I think 
this specialized map should support both const and non-const subscript, which 
doesn't agrees with lvalue property map requirements, it seems. 

Regards,
Vladimir