Re: [eigen] Addition to Eigen-unsupported Spline module

[Jeff J <complexzeros@xxxxxxxxx>]

Actually, it seems to be to avoid returning derivatives that are known to be zero in the case that the derivative order is greater than the degree of the spline.

On Fri, Jul 4, 2014 at 12:42 AM, Hauke Heibel <hauke.heibel@xxxxxxxxx> wrote:

Hi Jeff,

I don't remember anymore. I can only take care of this next week, or
maybe even the week after next week. I have two deadlines which I need
to take care of before I can handle the merge and other questions in
detail.

Thanks,
Hauke

On Fri, Jul 4, 2014 at 5:12 AM, Jeff J <complexzeros@xxxxxxxxx> wrote:
> Is there a reason for DerivativeType in SplineFwd.h to have a dynamic number
> of columns in the SplineTraits struct for fixed degree?
>
> typedef
> Array<_Scalar,_Dim,Dynamic,DerivativeMemoryLayout,_Dim,NumOfDerivativesAtCompileTime>
> DerivativeType;
>
>
>
>
> On Wed, Jun 25, 2014 at 7:06 PM, Jeff J <complexzeros@xxxxxxxxx> wrote:
>>
>> 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,
>>> gael
>>>
>>>
>>>
>>> On 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
>>>>> > ----------------------------------------------
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>