This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen

Bug 764

Summary: KnotAveraging should not assume input knots within [0, 1]
Product: Eigen Reporter: Bo Li <prclibo>
Component: Unsupported modulesAssignee: Nobody <eigen.nobody>
Status: NEW ---    
Severity: Unknown CC: hauke.heibel, prclibo
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: All   
URL: https://bitbucket.org/prclibo/eigen/commits/2733830f36151ecc7d814970b647f6b5bedf3ff5
Whiteboard:
Attachments:
Description Flags
a patch prclibo: review? (hauke.heibel)

Description Bo Li 2014-03-15 15:41:33 UTC
Created attachment 430 [details]
a patch

KnotAverging assumes input knots are within [0, 1] and extends the knot vector by 0 and 1 at the two ends. This does not work with arbitrary knots value. For example, [2, 3, 4, 5] might return something like [0, 0, 3, 4, 1, 1]. Here I guess [2, 2, 3, 4, 5, 5] should be a better result. 
SplineFitting uses the KnotAveraging function and is also influenced if user provides knot vector.
Comment 1 Hauke Heibel 2014-03-16 11:57:29 UTC
I am not really convinced that I should apply this fix. Its quite some time ago that I used the module.

Here are the reasons, why I am hesitant:

a) The function does exactly what it promises - it implements the method proposed in the Nurbs Book which guarantees knot vector values to be in the range [0;1]. This requires parameters from the same range.

b) We are not loosing functionality, it is just less convenient. Any parameter range can be normalized to [0;1]

c) I do not remember if the assumption that knot values are in the range [0;1] is used elsewhere. E.g. in lines 135, 136 (SplineFitting.h), it seems as if I am relying on that range. I am not sure. But does the interpolation work after applying your proposal? The function for computing chord lengths always returns normalized chord lengths. Should this be changed as well?

Please let me know what you think.

Regards,
Hauke
Comment 2 Bo Li 2014-03-17 05:39:12 UTC
Hi Hauke,

I don't have the Nurbs book so unfortunately I cannot dig into the book for this problem. But I suppose it will be good to allow arbitrary knots value since it is not usually convenient to do the normalization.

In SplineFitting.h, you are not assuming [0,1] knots input, which might lead to problem. The following is a small example with knots as (100, 101, ..., 109):

#include <cmath>
#include <iostream>
#include "Eigen/Dense"
#include "Eigen/Splines"

int main()
{
    Eigen::MatrixXd pts(2, 10);
    Eigen::VectorXd knots(10);
    for (int i = 0; i < 10; ++i)
    {
        pts(0, i) = i;
        pts(1, i) = sin(i)
        knots(i) = i + 100;
    }
    typedef Eigen::Spline<double, 2, Eigen::Dynamic> SplineType;
    SplineType spline = Eigen::SplineFitting<SplineType>::Interpolate(pts, 4, knots);
    for (int i = 0; i < 10; ++i)
        std::cout << pts.col(i).transpose() << " | " << spline(knots[i]).transpose() << std::endl;
}

SplineFitting results are:
0 0 | 1.59897e-05   -0.654944
       1 0.841471 |        1 0.841471
       2 0.909297 |        2 0.909297
      3 0.14112 |       3 0.14112
        4 -0.756802 |         4 -0.756802
        5 -0.958924 |         5 -0.958924
        6 -0.279415 |         6 -0.279415
       7 0.656987 |        7 0.656987
       8 0.989358 |        8 0.989358
       9 0.412118 |   9.00002 -0.178183
After the proposed fix:
0 0 | -3.44067e-17  1.37627e-17
       1 0.841471 |        1 0.841471
       2 0.909297 |        2 0.909297
      3 0.14112 |       3 0.14112
        4 -0.756802 |         4 -0.756802
        5 -0.958924 |         5 -0.958924
        6 -0.279415 |         6 -0.279415
       7 0.656987 |        7 0.656987
       8 0.989358 |        8 0.989358
       9 0.412118 |        9 0.412118
Comment 3 Nobody 2019-12-04 13:05:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/764.