> So just return v and the instantenous acceleration at time t?

Yes, exactly.

> It's news to me that C++ supports optional function arguments.

Of course it does (see printf) but you don't use that here.  You just define 
two functions with the same name but with different arguments (this is where 
the article text is a bit misleading IMO).  The compiler knows which one to 
actually call because it matches up the arguments.

> [And while we're on the subject, this is the first example of C++ code 
> I've ever seen which appears to be comprehensible. Usually it just looks 
> like gibberish...]

Maybe because it's written for the purpose of clarity rather than trying to 
make it look "clever" by being totally unreadable.

> So anyway, it computes several derivatives and takes their weighted 
> average. That seems simple enough in principle. I rather suspect that in 
> practice it's spine-tinglingly easy to screw up some tiny detail that 
> makes the entire algorithm not work properly. There's *a lot* of 
> individual steps there to get right...

Yeh, try it first with a simple model like a mass on a spring, or a 
pendulum.  You can then check the results with the actual theory of those 
models, and even compare to standard Euler at the same time.

When I first wrote my RK4 code for the thing I'm currently working on, I 
accidentally updated the initial state for each of the 4 derivative 
calculations.  It was only when I noticed that the velocities being reported 
didn't match up with the actual distances being covered (like covering 1km 
in 10 seconds at a speed of 20 m/s!) that I found the bug.

> Mmm, as with all adaptive algorithms, the key is to get the maximum step 
> size "small enought", and to avoid infinite recursion. (I also wondered if 
> maybe it would be better to just look at the magnitude of force changes or 
> something to decide how "stable" the system is at this point...)

A common method used in car simulations (where the tyres are very stiff and 
hence need a very small time step or the thing explodes easily) is to check 
that energy is (almost) conserved.  Going back to the simple mass/spring 
model, if you keep track of the kinetic energy in the mass and the spring 
energy stored, it should be fairly trivial to include a check if the total 
energy has suddenly spiked.  If so you could then do some smaller time 
steps.  Of course if you are getting input from outside the system you need 
to account for this too.

Post a reply to this message