Question: I've done a fair bit of reading on stepper motors and acceleration.
I had to wade through a lot of different strategies with a lot of calculations, including one which called for several candles, and "A maiden of virtue pure" Which while interesting, seemed impractical (Not enough space on the Arduino)
Basically they all boil down to this:
"Accelerate using some type of ramp, run at speed, then decelerate to stop"

All good. Accelerating will get the load moving, and smooth deceleration will get the load to stop at the (hopefully) correct position.

My issue is this. All of the reading I've done so far seem to have the assumption that the distance to travel will be enough to accommodate all three phases of travel. ie Accel, Coast at speed , Decel.
I've not found much discussion on how to handle very short distance situations.

For example, moving only two steps will not, can not possibly have enough distance to go through all three phases. step - step - done.
While that particular example seems to be simple enough to solve, what are the best ways of determining if deceleration is required, and if so, when?

At what point do I determine that some sort of deceleration profile will be needed to get the stepper to stop at the required position without overshooting.

---

So after a whole bunch more looking, and reading and getting confused I decided on the simplest solution.

I stayed with a trapezoidal/triangle profile.
Essentially I determined the distance a constant acceleration ramp would use to get to speed. If the acceleration distance was greater than half of the total distance to travel, I accelerate for only half the total travel distance and not worry about getting to max speed. Because I decided to use a symmetrical approach, the decel part took care of itself.

The equations I utilised are essentially the ones posted by Chuck, although the addition of different acceleration and deceleration rates he uses gives me food for thought.

Many, many thanks to all who contributed.

Answer: 
Well, for short runs, it should be obvious that you can skip the coast phase.

As for the others, it's pretty simple. Maintain constant acceleration until you are halfway to the target, then decelerate until you reach the target.

However, there's a catch (there always is, isn't there?). If you have misjudged the distance to the target, and it is closer than you think, then accelerating to your (erroneous) half-way point will mean that you will not be able to stop when you reach the real target point.
When planning a [trapezoidal move profile](https://robotics.stackexchange.com/a/7512/37), if you are not travelling far enough, it devolves into a triangular move. I.e. "accelerate, max velocity, decelerate", becomes "accelerate, decelerate".

I typically calculate cruise distance based on subtracting acceleration & deceleration distances (based on max. acceleration and max. velocity) from the total distance. If this cruise distance is negative, I recalculate acceleration & deceleration distances & velocities based on half the total distance (or the ratio of max acceleration & max deceleration if they are different).

Trapezoidal move profiles are often used because they are simple, and easy to calculate move speed and distance for each waypoint. The problem is, they are not very flexible, as they assume an instantaneous change in acceleration, which as we know is only an approximation to the behaviour of real systems.

Many move controllers have the option of using S-curve motion profiles. You start off by ramping up acceleration at the start of the acceleration phase, and ramping it down at the end, doing the same agasn at the start and end of the deceleration phase.

While it might seem logical that the fastest move you can do would involve accelerating at the highest rate possible, then decelerating at the highest rate possible, that may not always be the case. Reducing jolt (jerk) on a move by starting with a lower initial acceleration can enable you to maintain a higher peak acceleration for longer, resulting in a higher overall acceleration, all at the expense of more complex trajectory planning calculations.

This is especially a problem with stepper motors without encoders. Stepper motors suffer from the problem that if you demand they do something they can only just manage, their behaviour is unpredictable. Push your stepper motor just a little too hard and it will miss steps. If you don't have an encoder to detect these missed steps and correct for them (in your servo loop) then you will have to down-rate your max. acceleration parameter to the point that it can cope with all potential situations.

In general, you want to try to avoid discontinuities in control, so control algorithms should, much like the motors they control, transition smoothly between different modes of operation.