Closed hoechp closed 7 years ago
implement multiple different ways to do the check:
In an about 3 hour long sunday night hackathon, I implemented a whole new check for isomorphism based on the 'search problem' approach. It seems to work and it's about 50x faster on the graph in question, but it needs further testing.
Now I have all 3 approaches up and working. My initial 'combinatorial problem' approach seems to be always worse than the new 'search problem'/'CSP' approach, that pretty much is 100% solving a constraint satisfaction problem after limiting the variable domains as much as possible before starting the algorithm.
The new 'sorting problem' approach is very interesting, too. Since it yields a normal form for serializing a graph in a way, where two isomorph graphs will always have the same serialization. Not only 'academically valuable', this allows for easy repetative checks for isomorphism. Like when you have 100 Graphs, and you want to check them all against each other for isomorphism, you can just 'normalize' and serialize those, to then quickly do the check. Even if the normalization takes a while, it will eventually be worthwhile, if enough checks will be done with the obtained serialization.
still TODO:
found a bug in the search/CSP approach, where multiple nodes of one graph can be mapped to the same node in the other graph. and it's somehow harder to fix than it sounds, especially trying to not mess up performance
I found that my search/CSP approach wasn't working out the way I wanted. After reinventing it, what was left of it, was a dramatically enhanced version of my initial combinatorial approach. So I did just implement the new version and it seems to be much better than any previous implementation. It therefore unifies my CSP and combinatorial approach, so im left with just this new approach, you may also call it CSP-based rather than combinatorial - and then there's still the sort-based approach, that has a pretty bad performance unless, probably, you use it for hundrets or thousands of checks for isomorphism per 'normalized' graph.
The old CSP approach was buggy and will be deleted. I'm tending to keep the initial combinatorial approach though, even know it now is pretty much 'depricated'. But I'll keep the code in my project nevertheless.
I've found some graphs, where the check for isomorphism isn't that effective. The graph I first used to compare performance to SDMLib went pretty good, and this project was about 20x faster than SDMLib. After using an external expression library for attribute comparison, it is at least about 10x faster. But now I have a graph, which I didn't test in SDMLib, but it takes unreasonably long to do the check for isomorphism.
and the PatternGraph:
(the PatternGraph doesn't really play a role here, but it's here just to complete the example)
Checking if the graph is isomorph to a copy of it takes more than a minute or two, which is totally unreasonable for such a small graph.
I may have to rethink my whole concept of checks for isomorphism, or at least find a way to, once again, drastically increase performance of it.
I have three totally different approaches to the check:
All three approaches face the same kind of 'combinatorial explosion', that make the check become quite hard to complete in reasonable time, as the graph grows - strongly depending on 'how hard' the graph is to compare.
As I already put some time into the first approach, I think I should additionally try to implement one or even both of the other approaches, so I can compare them with one another. These things ain't trivial however and I'm running out of time, because this project is about to be finalized for now in the next one or two weeks. This will most probably be one of the last big issues I'll be facing here.