| | 1 | I haven't given a lot of thought to these since the semester just ended. However, I am starting to consider various type requirements for the algorithms and have spent some time playing with conceptg++. I did notice however, that there is a ticket already exists for finding cliques within a graph (#693) - even better, with links to source code. It might be worth pointing out, that the Bron and Kerbosch algorithm is written for a Boolean matrix so interpreting it for an adjacency list is a bit of a chore. I haven't actually read the other algorithm yet, hopefully it's promising. |
| | 2 | |
| | 3 | (Jeremy: btw, there is a matrix-as-graph adaptor in the BGL, and it would be straightforward to |
| | 4 | provide a graph-as-matrix adaptor.) |
| | 5 | |
| | 6 | On a side note, I started codifying the Boost.Graph graph concepts into a concepts header just to see if I could make it work - I haven't succeeded yet. Still, it's a good excercise and makes you think about concept hierarchies, nested requirements and the like. Also, i don't like the keyword `concept_map`. Not the idea itself - the keyword. If I'm not mistaken, this keyword replaces `model` from earlier proposals. Alas... |
| | 7 | |
| | 8 | (Jeremy: very cool! Yes, the `concept_map` keyword royally sucks. It turned out that `model` was |
| | 9 | already used in tons of C++ code, so we'd break that code if we turned `model` into a keyword.) |
| | 10 | |
| | 11 | Since I've been codigying graph concepts, I should point out that ''!IncidenceGraph'' and ''!EdgeListGraph'' both define `source()` and `target()` methods, so they're a little redundant. I think it would be appropriate to remove those methods from the requirements of ''!EdgeListGraph'' since they don't really have anything to do with the listing or enumerating of edges. Just a thought... |
| | 12 | |
| | 13 | (Jeremy: actually, `source()` and `target()` are pretty important to that concept. It would be better |
| | 14 | to refactor them into a common base concept.) |
