-
Notifications
You must be signed in to change notification settings - Fork 236
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
Introduce Eigen-style transpose() for Tangent-types #142
Comments
Just for clarification. I suppose you are aware that all our tangent types are Cartesian vectors, that is |
No, I don't think that affects the principal idea. Maybe an application example: what I would like to achieve is that one can evaluate quadratic forms like the following ...
... while using pure Eigen-syntax! Does that clarify the idea? |
Yes it does! Thanks. I'm mostly concerned with the math of the library. Jeremie is the one involved in the design / development of the library. Let us see what he says. |
Hi all, |
Yes, it makes perfect sense and you save a lot of work. I think the base API from Eigen can be exposed partially also, should some parts of it become irrelevant or dangerous for any reason, using the |
Inheriting from Eigen::Matrix seems like a good idea, I did not have that on my radar, but it probably makes sense for the Tangent class! |
Dear @artivis @joansola |
Hi @markusgft, |
No worries, I fully understand (it's the same for me and the control toolbox) and I certainly did not want to appear too demanding! |
From my side there's not much I can do. But I'd like to see this evolving since I believe this would be a powerful upgrade of the library. |
Hi guyz, Thoughts? |
Here's my thought. Implementing most of the Eigen API on top of manif is maybe a dumb option but very effective. It might be tedious but other than that it's a fine way to go. I wonder if we can design a macro of the style: MANIF_ADD_EIGEN_METHOD(MethodName, __VA_ARGS__) that would act as a bridge to call the Eigen method. I'd say also to put all this in a separate file to be able to cut it out one day. |
Hi @artivis, why should you inherit from MatrixBase rather than from Eigen::Matrix? Do you think exploiting static polymorphism is going to make such a massive difference here? Inheriting from Eigen::Matrix directly might be slightly less efficient, at the same time we do it in the control-toolbox, too, and do not have bad experience with that design. |
@joansola : @markusgft May I ask you to list the actual functions you are missing from Eigen? Is it only |
Dear @artivis, sorry for introducing such a long delay before my response, now I finally manged to come back to this thread. Here is a (preliminary) list of things that I currently have "hacked" myself into manif, and which would be fantastic to have in the main library.
Happy to discuss if you have questions! All the best! |
Hi @markusgft,
For manifold and tangent types, the The rest of the comment seems reasonable. I'll come back to it more in detail later on. |
Hi all, for completeness, the following design seems to work: struct TangentBase; // unchanged
struct SE2TangentBase : TangentBase; // unchanged
struct SE2Tangent : SE2TangentBase<SE2Tangent>, Eigen::Matrix<Scalar, 3, 1>; // change pro: we get to inherit the Eigen API at the most user-facing level
The first cons is imho the most annoying one. template <template <typename Derived> class Base>
struct proxy : Base<Derived>, Eigen::Matrix<Derived::Scalar, Derived::Dim, 1>;
struct SE2Tangent : proxy<SE2TangentBase<SE2>>; |
|
|
|
@joansola You are right, I was somehow blocked on |
|
Yes, I can see your point -- I can overload that locally in the CT. I only mentioned that because boost odeint requires the user to overload + in order to work. Another option would of course be to independently commit a set of corresponding operations to boost odeint, but I feel like this would be beyond our reach. A big +1 here from my side for the generic code argument! |
I'm taking the freedom to hijack this issue to pose a related question: why have a Pros:
Cons:
Of course I don't expect you to change such a fundamental part of the library, but I'm curious about the considerations that went into the choice. |
Allow me to start by being skeptical; I don't quite buy the performance boost argument. I'd need to see actual, significant, numbers. This being said, in hindsight Now, as for the reason of the tangent classes, well, call me old fashion but I like my object-oriented strongly-typed programming language. What's an template <typename Derived> void foo( TangentBase<derived>& tangent ) { auto g = tangent.exp(Jacobian) ... } I had a look at Eigen's Note that |
Appreciate the response! Yeah I'm aware of Regarding generic programming, unless I am mistaken a similar effect could be achieved by templating over the group type. Granted, it's a bit clunky since the compiler can't infer what tangent type template <typename Group, typename Derived> void foo(Eigen::MatrixBase<Derived> & tangent) {Group::exp(tangent) ... } I also looked into the plugin mechanism a couple of months ago after reading this thread, but came away with the impression that it wa a bad option. Even inheriting from somewhere in the Eigen hierarchy seemed tricky and I gave up my experiments, but I can't recall the exact reasons for why it was hard. |
Dear all,
what do you think of introducing an Eigen-style
transpose()
call for manif tangent types?The context of the question is the same as in #137.
So far, I helped myself with introducing the following public method to my personal clone of manifs
tangent_base.h
:Note that it in fact returns the transpose of the underlying data type, i.e. the transpose of an Eigen-matrix.
I would like to hear your opinion regarding such a feature, and like to suggest that this could also be helpful for other users?
Best!
The text was updated successfully, but these errors were encountered: