Incremental updates vs. direct computation: Further thoughts.
In my last post, I said:
My experiments within the spreadsheet suggest cumulative error from computing p(t) incrementally gets significant fairly quickly. I can compute p(t) directly, rather than incrementally computing a(t) to use to incrementally calculate v(t) to use to incrementally compute p(t). I just have to be careful to optimize that polynomial calculation as far as possible.
To expound on this a bit:
What I meant there was that it seems to be a bad idea to compute p(t) through either of the following incremental processes:
a(t) = a(t - 1) + k1
v(t) = v(t - 1) + a(t - 1)
p(t) = p(t - 1) + v(t - 1)
or even:
v(t) = v0 + k0 - (1/2)k1t2
p(t) = p(t - 1) + v(t - 1)
Instead, I really do need to calculate p(t) directly if I want the camera to land on-target every time. This isn't due to cumulative rounding error, since I could do that at infinite precision and still end up at the wrong destination. It's due to the fact I've tried to compute a continuous function in rather sloppily quantized discrete steps. To get it right, I'd have to come up with slightly more sophisticated delta updates. (ie. I'd have to find p(t - 1) and p(t) algebraically and subtract, rather than use these very simplified approximations.)
That's not too surprising, but it's a little annoying. It also means I won't have the value of v(t) handy if I shift focal points in the middle of a pan. That's not too awful, since I probably am safe estimating it by keeping p(t) and p(t - 1) around, and estimating v(t) as p(t) - p(t - 1).
I only need v0 so that the initial velocity of a new pan is pretty close to the velocity of the pan it just terminated. This is what gives C1 continuity, and a slight error there won't be noticeable.
I think if I find p(t) - p(t - 1) algebraically and then reduce that, I should be able to come up with a series of incremental updates that have no explicit multiplications. They'll be a little more subtle than the hamfisted incremental updates above, but they should be accurate. The downside is that I may expose myself to the possibility of round-off error unless I go to 32 bit precision. Since ttot is at most 128, which is 27, my maximum fraction length is 21 bits, and that's exact.
Why do I say it's exact? Recall my equations for k0 and k1:
k0 = 6D / (ttot2) - 4v0 / (ttot)
k1 = 12D / (ttot3) - 6v0 / (ttot2)
The only thing creating a fractional portion here is the division by ttot, which is a power of 2. I'll always have an exact number of fractional bits. Ok, that's not 100% true: v0 will have a fractional portion, but we already said it's ok if it gets approximated. Everything else coming into this computation is an integer.
My experiments within the spreadsheet suggest cumulative error from computing p(t) incrementally gets significant fairly quickly. I can compute p(t) directly, rather than incrementally computing a(t) to use to incrementally calculate v(t) to use to incrementally compute p(t). I just have to be careful to optimize that polynomial calculation as far as possible.
To expound on this a bit:
What I meant there was that it seems to be a bad idea to compute p(t) through either of the following incremental processes:
a(t) = a(t - 1) + k1
v(t) = v(t - 1) + a(t - 1)
p(t) = p(t - 1) + v(t - 1)
or even:
v(t) = v0 + k0 - (1/2)k1t2
p(t) = p(t - 1) + v(t - 1)
Instead, I really do need to calculate p(t) directly if I want the camera to land on-target every time. This isn't due to cumulative rounding error, since I could do that at infinite precision and still end up at the wrong destination. It's due to the fact I've tried to compute a continuous function in rather sloppily quantized discrete steps. To get it right, I'd have to come up with slightly more sophisticated delta updates. (ie. I'd have to find p(t - 1) and p(t) algebraically and subtract, rather than use these very simplified approximations.)
That's not too surprising, but it's a little annoying. It also means I won't have the value of v(t) handy if I shift focal points in the middle of a pan. That's not too awful, since I probably am safe estimating it by keeping p(t) and p(t - 1) around, and estimating v(t) as p(t) - p(t - 1).
I only need v0 so that the initial velocity of a new pan is pretty close to the velocity of the pan it just terminated. This is what gives C1 continuity, and a slight error there won't be noticeable.
I think if I find p(t) - p(t - 1) algebraically and then reduce that, I should be able to come up with a series of incremental updates that have no explicit multiplications. They'll be a little more subtle than the hamfisted incremental updates above, but they should be accurate. The downside is that I may expose myself to the possibility of round-off error unless I go to 32 bit precision. Since ttot is at most 128, which is 27, my maximum fraction length is 21 bits, and that's exact.
Why do I say it's exact? Recall my equations for k0 and k1:
k0 = 6D / (ttot2) - 4v0 / (ttot)
k1 = 12D / (ttot3) - 6v0 / (ttot2)
The only thing creating a fractional portion here is the division by ttot, which is a power of 2. I'll always have an exact number of fractional bits. Ok, that's not 100% true: v0 will have a fractional portion, but we already said it's ok if it gets approximated. Everything else coming into this computation is an integer.