On 12/8/2010 9:37 AM, Denis Lila wrote:
Shouldn't it be [A, B]?
I thought about this when implementing it, but I don't think it mattered
whether it was closed or half open, and the closed interval would have been
somewhat more awkward to implement.
I'm not sure how the closed interval is awkward. Isn't it just proper
choice of ">= and <= vs. > and <" in the testing method?
getMaxAcc functions - don't we want the furthest value from 0,
positive or negative? You are looking for most positive value
and negative accelerations are equally problematic, aren't they?
If so then these functions need some work.
You're right about both, but there's a much more serious problem that I
didn't think of when writing them: the value I compute in the if
statement in Dasher:355 is not an upper bound on the acceleration of
the curve. The acceleration is:
C'(t).dot(C''(t))/len(C'(t)) which in terms of the parameter polynomials is
(x'(t)*x''(t) + y'(t)*y''(t))/sqrt(x'(t)^2 + y'(t)^2)
What those functions would compute if they were "correct" would be
max(abs(x''(t))) and max(abs(y''(t))), and the sum of these is not
closely related to the maximum absolute acceleration, which is what we
want.
Without the upper bound property, I don't think it's a very meaningful
test, and I think we should abandon this optimization. Do you agree?
How about "if the 3 segments of the control polygon are all close to
each other in length and angle", then the optimization applies. Is that
easy to test?
...jim
