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

Template Rn for dimension to exploit performance of fixed-size Eigen objects #159

Merged
merged 19 commits into from
Apr 13, 2017

Conversation

jslee02
Copy link
Member

@jslee02 jslee02 commented Apr 6, 2017

TODOs:

  • Explicitly instantiates for frequently used dimensions
  • Use extern template to force the compiler not to instantiate for the explicitly instantiated types
  • Decide name: template <int N> class Rn vs template <int N> class R (I prefer R<N>)
  • Support dynamic size

Resolves #152

@jslee02 jslee02 requested a review from mkoval April 6, 2017 01:57
@jslee02 jslee02 changed the title Template Rn for dimension to exploit performance of fixed-size Eigen objects [WIP] Template Rn for dimension to exploit performance of fixed-size Eigen objects Apr 6, 2017
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling f06e949 on feature/template_rn_state_space into ** on master**.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling f06e949 on feature/template_rn_state_space into ** on master**.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.437% when pulling 4be2bb1 on feature/template_rn_state_space into a9b50ae on master.

@psigen
Copy link
Member

psigen commented Apr 7, 2017

I prefer the R<N> syntax. I think it makes semantic sense and then instantiations can look like R2 or R3.

…_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
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.403% when pulling 277698b on feature/template_rn_state_space into a59975f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.37% when pulling f1ffd63 on feature/template_rn_state_space into a59975f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.403% when pulling 82a9c6e on feature/template_rn_state_space into a59975f on master.

@jslee02 jslee02 changed the title [WIP] Template Rn for dimension to exploit performance of fixed-size Eigen objects Template Rn for dimension to exploit performance of fixed-size Eigen objects Apr 11, 2017
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.7%) to 84.487% when pulling ef80605 on feature/template_rn_state_space into a59975f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.403% when pulling 4810b2a on feature/template_rn_state_space into a59975f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.437% when pulling 4810b2a on feature/template_rn_state_space into a59975f on master.

Copy link
Member

@mkoval mkoval left a 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,
Copy link
Member

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? 😁

Copy link
Member Author

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>;
Copy link
Member

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>;
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Rename to RnConstantSampler?

Copy link
Member Author

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?

Copy link
Member

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());
Copy link
Member

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>;
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Rename to RnEuclidean?

/// 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();
Copy link
Member

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,
Copy link
Member

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?

Copy link
Member Author

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.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.403% when pulling 4e8eac0 on feature/template_rn_state_space into a59975f on master.

@psigen
Copy link
Member

psigen commented Apr 12, 2017 via email

@jslee02
Copy link
Member Author

jslee02 commented Apr 12, 2017

Rn is reserved for R<Eigen::Dynamic> so that it would be the same as before.

So we now have:

  • Rn = R<Eigen::Dynamic>
  • R0 = R<0>
  • R1 = R<1>
  • ...

I believe above is better looking than below:

  • Rnn = Rn<Eigen::Dynamic> // what?!
  • Rn0 = Rn<0>
  • Rn1 = Rn<1>
  • ...

@psigen
Copy link
Member

psigen commented Apr 12, 2017 via email

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.421% when pulling 0ff6170 on feature/template_rn_state_space into 3c9c8cc on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.8%) to 84.421% when pulling 0ff6170 on feature/template_rn_state_space into 3c9c8cc on master.

@jslee02 jslee02 added this to the Aikido 0.1.0 milestone Apr 12, 2017
@jslee02
Copy link
Member Author

jslee02 commented Apr 12, 2017

I wish C++ supports this syntax R<n>ConstantSampler (jk, that would be disaster 😨).

I believe mostly we might be using type aliasing for the templates like R2ConstantSampler so it would be fine with either template names. However, my concern with putting n to template names is using Rnn = Rn<Eigen::Dynamic>.

Anyways, I don't have a strong preference here as long as it makes sense. 😄

@mkoval
Copy link
Member

mkoval commented Apr 13, 2017

I slightly prefer R for the reason @jslee02 described - the aliases Rnn, RXd and Rxd are all very awkward for the Eigen::Dynamic alias. I could be convinced otherwise if @psigen is sufficiently stubborn. :neckbeard:

@psigen
Copy link
Member

psigen commented Apr 13, 2017

Guys, I am not opposed to R<> for the StateSpace, I am concerned about it for types like RBoxConstraint where it seems like:

using R2BoxConstraint = RBoxConstraint<2>

is not clearer than:

using R2BoxConstraint = RnBoxConstraint<2>

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.

  • One option could be to always just put the state space at the end like BoxConstraintR<2>.
  • Another option is to use a different placeholder, like:
    using R2BoxConstraint = RxBoxConstraint<2>
    using RnBoxConstraint = RxBoxConstraint<Eigen::Dynamic>
    

@jslee02
Copy link
Member Author

jslee02 commented Apr 13, 2017

I thought we all implicitly assume that we want to keep the consistency of R[n] and R[n]X classes.

The alternatives could be options, but RnBoxConstraint<N> is not consistent with R<N> and BoxConstraintR<N> is not consistent with the current naming convention (at least until now) of [SpaceName]OtherName.

I think we should choose which one we weight more between consistency and readability. 😓

@mkoval
Copy link
Member

mkoval commented Apr 13, 2017

I thought we all implicitly assume that we want to keep the consistency of R[n] and R[n]X classes.

I strongly agree. All of the other constraint classes are named like <StateSpace type><optional descriptor><constraint type>. Breaking this convention just for R<n> will cause me (and I suspect many others) endless frustration.

If it comes down to R<n> vs. consistency, I'd rather go with Rn<n> with consistent names.

@psigen
Copy link
Member

psigen commented Apr 13, 2017

I guess I'll just leave it up to you guys, but note that for strong consistency, the naming conventions end up being:

RJoint<N>  -> R2Joint
SOJoint<N> -> SO2Joint
SEJoint<N> -> SE3Joint
TJoint<N>  -> T2Joint

And if you are in a situation where the constraint takes some template parameter

RSomeConstraint<N, M> -> R3SomeMConstraint

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.

R<N> -> R2
RnBoxConstraint<N> -> R2BoxConstraint

Anyway, it's just a style opinion, so you guys should do whatever you conclude is best.

@jslee02
Copy link
Member Author

jslee02 commented Apr 13, 2017

I think RSomeConstraint<N, M> -> RNSomeMConstraint is acceptable.

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.

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 X for the aliasing name rather than the placeholder name), which I believe so, as:

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.

Anyway, it's just a style opinion, so you guys should do whatever you conclude is best.

I agree. I would like to vote to not using placeholder in template class name. 😓

@jslee02
Copy link
Member Author

jslee02 commented Apr 13, 2017

Alright, let's merge this as it is since at least we could use it as before (Rn[X] classes are the same), and revisit if necessary.

@jslee02 jslee02 merged commit 2b21ddd into master Apr 13, 2017
@jslee02 jslee02 deleted the feature/template_rn_state_space branch April 15, 2017 00:33
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.

4 participants