On Tue, Apr 29, 2014 at 01:46:05AM -0400, Papoj Thamjaroenporn wrote:
Hi Nathan,
Thank you for the email. I am currently booked right now but I will get back to you some time this week to investigate more on this issue.
No hurry.
Just one question: what exactly should I print out? I printed a segment of the curvature path (the 4th segment to be exact) in terms of Kxy, and this segment definitely wiggled, but the output was always the same when I hovered my mouse around:
ix: 4 Kxy[0]: {281.25, 290.625}s^0 + ix: 4 Kxy[1]: {372.08, 346.521}s^0 + {-28.7083, -45.4316}s^1 + {-8.2712, -12.9363}s^2 + {1.31768, -0.797948}s^3 + {0.739784, 0.184223}s^4 +
If Kxy is indeed stable, the problem might lie in the method cairo_d2_sb()somewhere.
Ok, given this I agree with your assessment. The bit that is most suspicious is in sbasis-to-bezier starting from:
// calculate Bezier control arms
if (std::abs(xprime[1]*yprime[0] - yprime[1]*xprime[0]) > 1.e-5) { // general case : fit mid fxn value
that if statement in particular could explain the strange switching behaviour. So what you might do is either put a breakpoint in that cost, or stick a cout << ... in there.
The other likely candidate is the adaptive subdivider code: if(tail_error(B, 3) < tol || sbasis_size(B) == 2) { // nearly cubic enough
but that's been pretty well tested I think.
njh