Regarding the GP's approach in general, chasing constant-factor improvements on problems like this isn't always worth it. Doing one pass isn't necessarily faster than two if (for example) you do twice as much work at each step.
Not to mention that measuring performance in "number of operations" is pretty vague to begin with unless you're digging all the way down to the generated assembly code and know how many clock cycles an ADD takes vs a MUL, etc. At that point you should probably just pull out a profiler =)
I guess it depends on where you work, I guess I've grown used to the more accurate complexities we use around here and forgot about the concrete theory. For us, twice the time is twice the time no matter how you sugar coat it.
So, uh, my bad. You are correct.
Which is funny, because your method still uses 2n multiplications, it just computes them in the same loop.
If you have a golden hammer, every problem looks like a red thumb.