On Sat, Nov 30, 2013 at 06:50:06AM -0800, alvinpenner wrote:
The behaviour of the tail_error(B, n) function in build_from_sbasis() inthe file sbasis-to-bezier.cpp has been reevaluated. The term tail_error(B, 2) is too large since it is of order 4 in theta, for an arc, while the error currently produced is of order 6 in theta. For this reason the term tail_error(B, 3) was investigated numerically to see how it behaves. By numerical printouts at different theta, it was found that for a unit circle the tail_error(B, 3) term is roughly given by : 0.000022*(theta)^6. This agrees surprisingly well with the formula given above for the case where the sbasis is fit at t = 0.5. The formula given above was: error = (2/27)*(theta/4)^6. The difference between these results is only 20%, which I find surprising given the very different histories of the two calculations. In any event, I would like to propose that the term tail_error(B, 3) be used to determine the error estimate when bisecting the sbasis curves to meet the required tolerance. If this is done, numerical tests indicate that the dividing point in switching from 4 Beziers to 8 Beziers for a full circle will occur at r = 407 instead of the current r = 8.18.
Hi Alvin,
Good sluthing!
This is puzzling, I think it must be due to the fact that you are using geometric subdivision (putting the new control points on the circle) rather than parametric (subdividing the higher order splines), because the tail_error(B, 2) value should be fairly tight. Can you check the analysis and see if we didn't make a silly out-by-one error in the api.
I agree with your assessment though, let's switch to tail_error(B, 3) and see if anyone complains.
njh