Summary:  KnotAveraging should not assume input knots within [0, 1]  

Product:  Eigen  Reporter:  Bo Li <prclibo>  
Component:  Unsupported modules  Assignee:  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: 

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 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.59897e05 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.44067e17 1.37627e17 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  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. 
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.