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

Add position to Point2 nodes in GraphViz #1058

Merged
merged 1 commit into from
Jan 24, 2022

Conversation

senselessDev
Copy link
Contributor

I had the problem that with me using the Python binding the position of Point2 nodes were not present in the GraphViz code of saveGraph.

After a little bit of debugging I knew why. When inserting values like so

values = gtsam.Values()
values.insert(0, gtsam.Point2(100, 200))
values.serialize()

the result gives a hint about the values type:

 '22 serialization::archive 15 1 0\n0 0 0 1 0 2 34 gtsam::GenericValue<gtsam::Vector> 1 0\n1 0 0 0 0 2 1.00000000000000000e+02 2.00000000000000000e+02\n

It is a gtsam::Vector which is equivalent to (Eigen::Matrix<double, -1, 1, 0, -1, 1>) meaning the dynamic vector type. Thus, the dynamic_casts near the diff can't capture the values I added in this way.

This PR would also capture those. But I don't know if it is a good idea because maybe some other factors have this underlying type where it has no positional meaning. So that's the first point to discuss.

After having implemented this "fix", I additionally stumbled over the following difference when using this kind of value adding:

values = gtsam.Values()
values.insert_point2(0, gtsam.Point2(100, 200))
values.serialize()
'22 serialization::archive 15 1 0\n0 0 0 1 0 2 34 gtsam::GenericValue<gtsam::Point2> 1 0\n1 0 0 0 0 1.00000000000000000e+02 2.00000000000000000e+02\n'

As you can see, the type has changed and it is of a fixed size Eigen matrix (Eigen::Matrix<double, 2, 1, 0, 2, 1>). This type also gets correctly captured by the existing GraphViz formatting code. So the second point of discussion is if this PR is needed at all then. If it is not needed, I'd argue that the examples should not use the generic insert then. And I guess it should be documented somehow such that any beginner like me is not wondering why it is not doing what it should.

@ProfFan
Copy link
Collaborator

ProfFan commented Jan 22, 2022

This is an issue with the Python wrapper after we moved everything to just use numpy arrays. There is really no easy way to determine whether you want a fixed size vector or a dynamic vector. So GTSAM.Point2 in Python is just a shim function to create a numpy array, which is dynamic. add_point2, however, does the correct thing. In most code this is fine, but yes, it is still an issue and should be documented somewhere.

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.

I like it :-)
About examples not using insert_point2: can you point to specific examples so I can take a look? Wondering why other things don't go wrong...

@senselessDev
Copy link
Contributor Author

The example I had it from is

initial_estimate.insert(L1, gtsam.Point2(1.80, 2.10))
initial_estimate.insert(L2, gtsam.Point2(4.10, 1.80))

@dellaert dellaert merged commit f9d1af3 into borglab:develop Jan 24, 2022
@dellaert
Copy link
Member

Thanks !!!

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.

3 participants