Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix(Inference): Work harder in variable instantiation #591
fix(Inference): Work harder in variable instantiation #591
Changes from 12 commits
61ce9a0
456e55b
802b011
c043802
fad983e
d49926d
983bb3a
e5dbc78
80516c3
84bffa8
4530168
a94d2c8
52fe101
fada318
a1fb7ec
4f62200
ea3c102
9f032d6
6f288cd
c04e302
8e87d3e
9d49c29
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
The thing that bothers me a bit here is that we don't have much of a guarantee that
relations.ccs()
contains every node that we didn't add a solution for earlier. (That guarantee comes from the idea that only if there was a cyclic dependency would we have failed to find a solution earlier, so every node added to relations must be in a cycle, but still.)One possible answer?? Don't mutate via
self.add_solution
but return a completeMap
. Then you can assert that the map has the right number of entries (same asvariable_scope.len()
). Then you can add that Map toself.solutions
all in one go (afterdebug_assert!
ing that the keyset is disjoint, as perfn add_solution
)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.
(There are other ways, you could record the
m
s for which the first loop failed to find a solution, then tick them off here. But that'd be more expensive when debug_assert is disabled)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.
We could add an assert that the number of nodes in
relations.css()
(flattened) is the same as the length ofvariable_scope
?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.
You'd need to filter out the number of those that were already in
self.solved
(there's anif !self.solved.contains
)...But the flattening idea is good - how about just that the number of nodes in flattened-
relations.css()
is equal to the number of edges in relations?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.
Ah ok, some edges share endpoints. This works:
Common up the two
relations.ccs
tho!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'm not sure that check really makes sense, since it's apparent that the size of
node_map
and the number of nodes in the graph will be the same from looking atGraphContainer::add_or_retrieve
, andscc
s will return a clustered version of every node in the graphThere 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.
Agreed size of node map equals number of nodes in the graph, yes the latter is what I meant.
But SCC = Strongly Connected Component, i.e. every node reaches every other? In a directed graph? Ah, are
ccs
undirectly-connected?So A -> B -> C -> A is one SCC, with all three nodes. But A -> B -> C is NOT an SCC by that definition, but are you saying that
.ccs()
would give you[[A],[B],[C]]
?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.
Yes, indeed it does. In which case yeah, no assert/check really seems necessary, we're only really protecting against somehow getting in a muddle ourselves between the two loops.
Does make me wonder whether we could just put everything through the
relations
map, then. A node with no connections will trivially (and cheaply) be its own SCC. So this above:could just be
and then all the
add_solution
calls would be in the second loop.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.
We don't need to add to
solutions
here do we? What if we had, say, two SCCs with an edge between them:I note Petgraph's
tarjan_scc
returns the components in a defined order (reverse topsort or something), so in theory (maybe you have to reversecc
) it's soluble, but I think you need to consider not justsolutions.get(m)
for each m in the SCC but the solutions to the constraints uponm
(which by that topsort ordering have already been computed).Or, maybe such a structure can't occur, I dunno....????
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.
Try branch
inference-variable/fix-dependent-sccs
(the last commit) - some uncertainties detailed in the comments there, and needs a test of a structure such as the ABCDEF above.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.
Ooops, realize that wasn't passing tests! A missed
self.resolve
should make it pass now.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.
Hahaha! Neat :-) You might consider
flat_map
(*3) to avoidmut
but like it either way :)