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() in
the 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