-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better hasEdge for Algrebra.Graph #88
Conversation
This is obviously related to #84 |
Well it worked, but only when dealing with non-loop :p The corrected version is passing tests and is a bit slower than the faulty one of course. Mesh
Clique
|
Bang patterns wasn't useful and does not worked with old GHCs. Thanks travis ! Mesh
Clique
|
@nobrakal What about doing a simple check at the beginning: if |
I don't know if it worth it: the version with tuples (the last one) is almost the same time than my first faulty version, and is working in any cases. It must be a little worse in term of space use (I am storing two booleans instead of one for matching vertex), but I don't think this is an issue ^^. |
@nobrakal I am concerned with the complexity of the current solution: it is hard to understand and it's not immediately obvious that it is correct. By checking for self-loops separately, we can potentially get two benefits:
|
@nobrakal Wow, is it 4 times faster now? |
It seems yep ^^. Maybe this is a bit overestimated. I have ran the benchs on my machine with bigger graphs, and it is more about Just updated this PR using your suggestion. It worth anyway to test the loop presence more than I thought :) Here:
Mesh
Clique
SUMMARY:
There was 4 ex-aequo ABSTRACT:
Please note that the benchs were run on another machine than the previous one, so I think trying to compare them with my previous comments does not make many sense. |
@nobrakal I have another (very low-level) optimisation in mind, but I think we can try it separately :) Could you do the same change to Can this be used in |
Haha, you awaken my curiosity ^^
I think I have already done it ^^: 9111701
It has I think it heavily depends on the removing of |
Oops you were right, I just added the corresponding change for |
@nobrakal Thanks! Does this optimisation make sense for |
@nobrakal Looks like there are now some conflicts. |
Using the still-hot NFData instance of Fold, I found that the optimization makes sense for it :) hasEdgeDescription: Test if the given edge is in the graph (with arguments both in the graph and not in the graph (where applicable)) Clique
Mesh
SUMMARY:
ABSTRACT:
hasSelfLoopDescription: Test if the given self-loop is in the graph (with arguments both in the graph and not in the graph (where applicable)) Clique
Mesh
SUMMARY:
ABSTRACT:
|
@nobrakal Great! But what happened with Travis non-empty instance? |
My bad, my script is very sensitive (maybe too much) to any change in then benchmark suite. |
@nobrakal Why do we no longer have changes to non-empty graphs? Did your commit get lost? |
I totally forget about this PR while doing #94 so I blindly added the optimization to it. So it is already in place for |
@nobrakal Aha, I see! Thanks, merged :) |
Hi,
I have played again a bit, but I think I have found a better one this time :)
The boost come from two things:
induce (\x -> elem x [u,v])
was not a great idea. Just replacing it byinduce (\x -> x == u || x == v)
is clearly a better idea:Clique
ToGraph
:It is a bit more complicated, but it drops the
Ord
instance previously required to anEq
one:Mesh
Clique
SUMMARY:
ABSTRACT:
(Based on an average of the ratio between largest benchmarks)
And this rocks also with alga's clique:
Alga's Clique