-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add capability for Parallel reverse order #3
Conversation
def parallel_reverse_order | ||
parallel_order.reverse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should work, but my graph theory knowledge isn't quite advanced enough to convince me that its optimal... I'm just thinking of something like
B depends on A
C depends on A
D depends on C
In that case, I'd expect forwards to be [[A], [B,C], [D]]
But in reverse, couldn't we do [[B, D], [C], [A]]?
i.e. is optimal computed by "reverse the direction of the edge between each pair of nodes", and then recompute parallel_order on the resulting graph? I'm in over my head here...
I think what you've got works though, and is probably fast enough and more readable than something optimal(assuming this isn't already optimal).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be curious to see what this implementation could look like. I think this is good enough for now though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Adverbly I agree. I think your example correctly points out that the simply reversing the parallel_order
may not yield the same result as re-running the algorithm on the reversed dependencies themselves. I'm unsure at this time if this could result in errors (I can't think of any cases where it would be an issue), so until we actually encounter a problem with this, I'd say it's good enough.
def parallel_reverse_order | ||
parallel_order.reverse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be curious to see what this implementation could look like. I think this is good enough for now though
Version/CHANGELOG? |
def parallel_reverse_order | ||
parallel_order.reverse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Adverbly I agree. I think your example correctly points out that the simply reversing the parallel_order
may not yield the same result as re-running the algorithm on the reversed dependencies themselves. I'm unsure at this time if this could result in errors (I can't think of any cases where it would be an issue), so until we actually encounter a problem with this, I'd say it's good enough.
Closing this PR as it's not optimal enough. |
Add the ability for Dagwood to do reverse parallel order.
I did some testing manually on console so let's take an example of the below dependency tree:
This is what we have when we do
parallel_reverse_order
: