-
Notifications
You must be signed in to change notification settings - Fork 30
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
Template Rn for dimension to exploit performance of fixed-size Eigen objects #159
Conversation
Changes Unknown when pulling f06e949 on feature/template_rn_state_space into ** on master**. |
Changes Unknown when pulling f06e949 on feature/template_rn_state_space into ** on master**. |
I prefer the |
…_state_space Conflicts: src/constraint/uniform/RnBoxConstraint.cpp src/constraint/uniform/RnConstantSampler.cpp src/statespace/Rn.cpp tests/constraint/PolynomialConstraint.cpp tests/trajectory/test_Interpolated.cpp
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.
A few minor comments, but generally looks good.
statespace::dart::R1Joint, | ||
statespace::dart::R2Joint, | ||
statespace::dart::R3Joint, | ||
statespace::dart::R6Joint, |
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.
Could we add R<Eigen::Dynamic>
here 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.
All the RnX
classes support Eigen::Dynamic
, but not for RnJoint
. This is because all the dimensions of joints are determinant in compile time. More importantly, dynamic size dimension is not supported by none of DART's joint classes.
using R2BoxConstraint = RnBoxConstraint<2>; | ||
using R3BoxConstraint = RnBoxConstraint<3>; | ||
using R6BoxConstraint = RnBoxConstraint<6>; | ||
using RxBoxConstraint = RnBoxConstraint<Eigen::Dynamic>; |
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.
Nit: Rename to RnBoxConstraint
?
using R2ConstantSampler = RnConstantSampler<2>; | ||
using R3ConstantSampler = RnConstantSampler<3>; | ||
using R6ConstantSampler = RnConstantSampler<6>; | ||
using RxConstantSampler = RnConstantSampler<Eigen::Dynamic>; |
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.
Nit: Rename to RnConstantSampler
?
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.
Which means, we also rename the template class RnConstantSampler
to RConstantSampler
, right?
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, I think that makes sense if we renamed Rn
to R
.
bool RnBoxConstraintSampleGenerator<N>::sample( | ||
statespace::StateSpace::State* _state) | ||
{ | ||
Eigen::VectorXd value(mDistributions.size()); |
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 think this can be Eigen::Vector<double, N, 1>
.
using R2Euclidean = RnEuclidean<2>; | ||
using R3Euclidean = RnEuclidean<3>; | ||
using R6Euclidean = RnEuclidean<6>; | ||
using RxEuclidean = RnEuclidean<Eigen::Dynamic>; |
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.
Nit: Rename to RnEuclidean
?
include/aikido/statespace/Rn.hpp
Outdated
/// state space becomes a dynamic size real vector space; if N is a | ||
/// non-negative, then this state space becomes a \c N dimensional fixed size | ||
/// real vector space. | ||
R(); |
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.
This should throw an exception if N
is Eigen::Dynamic
, because there is no way to resize it.
template <int N> | ||
R<N>::R() | ||
{ | ||
static_assert(N > -2, |
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.
N >= 0 || N == Eigen::Dynamic
would be cleaner, since it doesn't assumeEigen::Dynamic = -1
.- Can we add a
static_assert(N != Eigen::Dynamic)
to avoid the edge case below?
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.
N >= 0 || N == Eigen::Dynamic would be cleaner, since it doesn't assume Eigen::Dynamic = -1.
👍
Can we add a static_assert(N != Eigen::Dynamic) to avoid the edge case below?
I instead changed to throw exceptions for that case because that wouldn't be compiled whenever N == Eigen::Dynamic
.
Wait a second, doesn't it make sense to leave the template as Rn? I read it
as `Rn<where n=1>`
|
So we now have:
I believe above is better looking than below:
|
I agree with `R<n>` but it looks much weirder with `RConstantSampler<2>`
where it is unclear what word the template parameter is associated with.
|
I wish C++ supports this syntax I believe mostly we might be using type aliasing for the templates like Anyways, I don't have a strong preference here as long as it makes sense. 😄 |
Guys, I am not opposed to
is not clearer than:
because the template parameter is nowhere near the thing it is attached to, and it is less obvious what the R means on its own.
|
I thought we all implicitly assume that we want to keep the consistency of The alternatives could be options, but I think we should choose which one we weight more between consistency and readability. 😓 |
I strongly agree. All of the other constraint classes are named like If it comes down to |
I guess I'll just leave it up to you guys, but note that for strong consistency, the naming conventions end up being:
And if you are in a situation where the constraint takes some template parameter
If you think those are acceptable, then by all means go for it. Personally I think this leads to making it hard to tell how the template parameter is going to affect the substituted name, given that it inserts a number in the middle of the original name in this convention. But I also don't really have a problem with inconsistent naming between the state spaces and templates that use them, e.g.
Anyway, it's just a style opinion, so you guys should do whatever you conclude is best. |
I think
I agree with you, but I also don't know what would be the better alternative under the current convention. I think using different placeholder could be an option as you commented above unless we will support resizable statespace (in this case, we might prefer using R2 = Rx<2>
using Rn = Rx<Eigen::Dynamic>
using R2BoxConstraint = RxBoxConstraint<2>
using RnBoxConstraint = RxBoxConstraint<Eigen::Dynamic>
using R2BoxSome3Constraint = RxBoxSomeMConstraint<2, 3>
using RnBoxSome3Constraint = RxBoxSomeMConstraint<Eigen::Dynamic, 3> However, we might have additional style issue if we start to put placeholder to template class name: upper letter vs. lower letter.
I agree. I would like to vote to not using placeholder in template class name. 😓 |
Alright, let's merge this as it is since at least we could use it as before ( |
TODOs:
template <int N> class Rn
vstemplate <int N> class R
(I preferR<N>
)Resolves #152