Re: [eigen] Addition to Eigen-unsupported Spline module |
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
Thanks, I fixed the testing..Regarding PartialPivLU, I don't want to use that because, in general, the matrix isn't guaranteed to be invertible, so I'm switching back to HouseholderQR. It's good enough for my purposes.On Wed, Jun 25, 2014 at 12:09 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
Don't bother too much with the static assertion. We can add it later on, but basically you have to add an enum in Core/utils/StaticAssert.h and then use EIGEN_STATIC_ASSERT(NumTraits<T>::IsInteger, BLA_BLA_BLA).Regarding the accuracy, the unit frequently fails even with FullPivLU, and I did not observed any improvement of using the much more costly FullPivLU compard to PartialPivLU. So I'd rather move back to PartialPivLU and update the unit tests to:VERIFY_IS_APPROX(point,referencePoint);....VERIFY_IS_APPROX(derivative, referenceDerivative);Moreover the "main" should iterate like this:void test_splines(){for(int k=0; k<g_repeat; ++k){CALL_SUBTEST( eval_spline3d() );CALL_SUBTEST( eval_spline3d_onbrks() );CALL_SUBTEST( eval_closed_spline2d() );CALL_SUBTEST( check_global_interpolation2d() );CALL_SUBTEST( check_global_interpolation_with_derivatives2d() );}}cheers,gaelOn Tue, Jun 24, 2014 at 4:51 PM, Jeff J <complexzeros@xxxxxxxxx> wrote:
Sorry, I'm not experienced with templates, but is there a preferred way of doing such static assertion in Eigen? Maybe an example somewhere?On Tue, Jun 24, 2014 at 5:01 AM, Hauke Heibel <hauke.heibel@xxxxxxxxx> wrote:Ok, sounds good. For the moment, we can at least static assert that
the Scalar of the array/vector is integral.
Hauke
On Tue, Jun 24, 2014 at 12:53 PM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 24.06.2014 12:24, Hauke Heibel wrote:
>>
>> What Christoph said backs up introducing a new typedef like e.g.
>>
>> EIGEN_MAKE_ARRAY_TYPEDEFS_ALL_SIZES(DenseIndex, Idx)
>>
>> Are there any objections about doing this? I am fine with it. That's all
>> which keeps us from merging.
>
>
> Well, I'm not objecting this, but I think it would be much easier to simply
> accept any type for derivativeIndices (the same as you do for
> PointArrayType). Then the code would work for Eigen::ArrayXi as well as
> std::vector<short>, etc, and you would not need to introduce a new typedef.
> I doubt that anyone will have splines with more than 2^31 nodes in the near
> future, so requiring 64 bit indexes seems a bit over-engineered for this
> (for people requiring this it would be possible, nonetheless).
>
>
> For a clean solution, I'd like to have some kind of static assertion which
> ensures `typename IndexArray` has a size() method, and an operator[] which
> returns an integer type. Later on specializations which determine if the
> size is fixed at compile-time might come handy.
>
>
> Regards,
>
> Christoph
>
>
>
> --
> ----------------------------------------------
> Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
> Cartesium 0.049
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
>
> Tel: +49 (421) 218-64252
> ----------------------------------------------
>
>
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |