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

Fix minor stuff #920

Merged
merged 7 commits into from
Nov 11, 2021
Merged

Fix minor stuff #920

merged 7 commits into from
Nov 11, 2021

Conversation

varunagrawal
Copy link
Collaborator

A bunch of minor fixes I made along the way.

@varunagrawal varunagrawal added the cleanup Help clean up old/obsolete aspects of GTSAM label Nov 9, 2021
@varunagrawal varunagrawal self-assigned this Nov 9, 2021
@@ -36,17 +36,17 @@ namespace gtsam {
// no Ordering is provided. When removing optional from VariableIndex, create VariableIndex
// before creating ordering.
VariableIndex computedVariableIndex(asDerived());
return eliminateSequential(function, computedVariableIndex, orderingType);
return eliminateSequential(orderingType, function, computedVariableIndex);
Copy link
Contributor

Choose a reason for hiding this comment

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

thanks for the PR, Varun.

Why change the order of variables here? breaks backwards compatibility perhaps?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It doesn't because this is a function call within another function aka the public API is still the same.

Fan and I discovered that the original function call was just calling this function, so instead of the indirect call, we save on the call stack by making this call directly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Another way to think of this is that we're just calling another version of an overloaded function, but with the added benefit of reducing the call stack, thus minor gains in efficiency plus easier to read the stack trace during debugging.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, makes sense. Could you add a link to the old wrapper function and the new function we're calling directly? Which file are they in?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the original one which is deprecated (though not properly).

boost::shared_ptr<BayesNetType> eliminateSequential(

This is replaced by this

boost::shared_ptr<BayesNetType> eliminateSequential(

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. So now we are using overloaded versions with boost "none" defaults for missing args. I wonder if we should make a TODO or note to ** fully ** remove the deprecated one as well

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yup, that's issue #889

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We don't do TODOs here, we make issues haha


if __name__ == "__main__":

def main():
Copy link
Contributor

Choose a reason for hiding this comment

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

nit return type here --

def main() -> None:

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Adding a return type declaration for None is questionable, since is it even useful? If the return type is something non-trivial, then it helps with things like linting and autocomplete, but None doesn't help with any of that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's useful purely for complete static analysis

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But does the static analysis report it missing? I have all warning enabled (even for the linter) and I get no warnings.

python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved

def run(args):

def run(args: argparse.Namespace):
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: missing return type

python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
Copy link
Contributor

@akshay-krishnan akshay-krishnan left a comment

Choose a reason for hiding this comment

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

All comments I have are a subset of John's, so feel free to merge once he approves.

python/gtsam/examples/SFMExample_bal.py Outdated Show resolved Hide resolved
DEFAULT_BAL_DATASET = "dubrovnik-3-7-pre"


def plot_scene(scene_data: gtsam.SfmData, result: gtsam.Values):
Copy link
Contributor

Choose a reason for hiding this comment

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

looks good. nit here: missing return type

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sorry, I don't see the utility of adding a None return type specification. Unless there is a compelling reason for this, we are losing the forest for the trees.

Copy link
Contributor

Choose a reason for hiding this comment

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

For me, it makes it easier to immediately understand the function signature.

If we don't have it, the type annotations are not complete, and we can't rely on mypy or other static analyzers completely.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If it's missing, we should be able to assume default None if the docstring doesn't mention a return type. No return type == None makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

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

We can infer that, but mypy can't : - )

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Mypy doesn't report None violations regardless. I added -> None to the run function and did x = run(parser.parse_args()), then I ran mypy and mypy didn't report any issue here, which is the correct behavior.

This goes back to my original comment, this would be useful for autocomplete. However, we're missing the main point that the wrapper doesn't provide type definitions out of the box, so mypy will fail on a lot of other things related to GTSAM before a missing return type None. Plus, we don't even check for type definitions in the CI, so again, I don't see a compelling reason for this review request.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added in the type-hints.

from gtsam import (GeneralSFMFactorCal3Bundler,
PriorFactorPinholeCameraCal3Bundler, PriorFactorPoint3)
from gtsam.symbol_shorthand import C, P
from gtsam.utils import plot
Copy link
Contributor

@johnwlambert johnwlambert Nov 10, 2021

Choose a reason for hiding this comment

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

I would import this as something like

import gtsam.utils.plot as gtsam_plot_utils

or

import gtsam.utils.plot as gtsam_plot

Otherwise I get confused about whether this is matplotlib

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Which is why I had the functions imported directly. 🙂
If we are okay with that, I can revert to the function import, since this is the case everywhere in the examples.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think if it's wrong in the other examples, we can slowly make the correct code go viral, starting from here : - )

Importing functions should not be allowed. But if you prefer calling it plot, feel free to leave this change as you have it here

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

What's the reason for that? Google's style guide mentions Use import statements for packages and modules only, not for individual classes or functions, so we're clearly not abiding by this. 🙂

Plus, I am of the opinion that these are guidelines and not the rules, so we can not conform to them if it means the code is more readable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Also, ironically, calling it gtsam_plot_utils is no better than simply doing gtsam.utils.plot.whatever_func.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think many modern Python libraries like Pytorch abide by this. Otherwise it's hard to immediately tell where to go to look for the implementation of a function (do I ctrl-F in this file, or look in another file)

Interesting that Google style forbids the class import, though.

Copy link
Collaborator Author

@varunagrawal varunagrawal Nov 10, 2021

Choose a reason for hiding this comment

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

Pytorch does something way wackier. Plus they have a bunch of people making 200K a year for this stuff, not 22K a year like yours truly. 🙂

If you paid me that much money, I'd be more than happy to accommodate this request. 😂

Copy link
Contributor

@johnwlambert johnwlambert left a comment

Choose a reason for hiding this comment

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

LGTM except I prefer the additional type hints. Rest looks good.

@@ -36,17 +36,17 @@ namespace gtsam {
// no Ordering is provided. When removing optional from VariableIndex, create VariableIndex
// before creating ordering.
VariableIndex computedVariableIndex(asDerived());
return eliminateSequential(function, computedVariableIndex, orderingType);
return eliminateSequential(orderingType, function, computedVariableIndex);
Copy link
Contributor

Choose a reason for hiding this comment

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

I see. So now we are using overloaded versions with boost "none" defaults for missing args. I wonder if we should make a TODO or note to ** fully ** remove the deprecated one as well

Because my time is more valuable than a reviewer's pedanticness
@varunagrawal varunagrawal merged commit f454bcb into develop Nov 11, 2021
@varunagrawal varunagrawal deleted the fix/minor-stuff branch November 11, 2021 03:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Help clean up old/obsolete aspects of GTSAM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants