Skip to content
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

DefaultOrderingFunc in EliminationTraits #1373

Merged
merged 7 commits into from
Jan 8, 2023
Merged

Conversation

varunagrawal
Copy link
Collaborator

@varunagrawal varunagrawal commented Jan 6, 2023

Added a new trait variable DefaultOrderingFunc in EliminationTraits so that specifying the ordering is now optional for Hybrid Factor Graphs.

This change is completely backwards compatible since I've simply set the DefaultOrderingFunc for the existing graph types to their previous defaults.

@dellaert seems like your formatter is still broken. Python tests ended up getting formatted, but the change is just me removing the ordering from calls to eliminateSequential and eliminateMultifrontal.

@varunagrawal varunagrawal requested a review from dellaert January 6, 2023 15:16
@varunagrawal varunagrawal self-assigned this Jan 6, 2023
@dellaert
Copy link
Member

dellaert commented Jan 6, 2023

Ah, I thought you had added a default Ordering::OrderingType. Would that not be simpler?
Also, PR is polluted with pruning test, please move that to a different PR?

@varunagrawal
Copy link
Collaborator Author

varunagrawal commented Jan 7, 2023

Ah, I thought you had added a default Ordering::OrderingType. Would that not be simpler?

I am not sure how that what would work. OrderingType is an enum while we only have a hybrid ordering function, no enum type Ordering::HYBRID and I wanted to avoid adding that for reasons I explain below. If I specify OrderingType's default as COLAMD, that won't work for Hybrid since it uses a custom ordering scheme.

Maybe in the future we can update the Ordering::Colamd method to handle discrete variables as well. This would then allow us to use Ordering::COLAMD as the OrderingType in lieu of a Ordering::HYBRID type.

Also, PR is polluted with pruning test, please move that to a different PR?

Thanks for catching that. Removed from this PR.

Copy link
Member

@dellaert dellaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. I will merge this, and then resolve conflicts in the refactor.

@dellaert dellaert merged commit 690a230 into develop Jan 8, 2023
@dellaert dellaert deleted the default-ordering-func branch January 8, 2023 01:35
@dellaert dellaert restored the default-ordering-func branch January 8, 2023 01:35
@dellaert
Copy link
Member

dellaert commented Jan 8, 2023

@varunagrawal I restored the branch, I'll let you delete it.

@varunagrawal varunagrawal deleted the default-ordering-func branch January 8, 2023 03:05
}
}

const VariableIndex index(graph);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@varunagrawal you potentially introduced a performance loss here, as you are not taking an optional variable index. It might have already been computed and passed in (in fact, we do that by default).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DefaultOrderingFunc takes an optional VariableIndex. We'll just have to update the HybridOrdering function to deal with that.

Indeed the continuous only version handles the variable index so there should be no performance loss in terms of backwards compatibility.

@dellaert dellaert added this to the Hybrid Inference milestone Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants