Let me weigh in here with a few words of caution, prefaced with a story. Long ago, I worked with a fellow when I was just starting out. He had an optimization problem to solve, with a rather messy objective. His solution was to generate the analytical derivatives for an optimization.
The problem that I saw was these derivatives were nasty. Generated using Macsyma, converted to fortran code, they were each dozens of continuation statements long. In fact, the Fortran compiler got upset at that, as it exceeded the maximum number of continuation statements. While we found a flag that allowed us to get around that problem, there were other issues.
In long expressions, as are commonly generated by CA systems, there is a risk of massive subtractive cancellation. Compute lots of big numbers, only to find they all cancel each other out to yield a small number.
Often analytically generated derivatives are actually more costly to evaluate than are numerically generated derivatives using finite differences. A gradient for n variables may take more than n times the cost of evaluating your objective function. (You may be able to save some time because many of the terms can be re-used across the various derivatives, but that will also force you to do careful hand coding, instead of using computer generated expressions. And any time you code nasty mathematical expressions, the probability of an error is not trivial. Make sure you verify these derivatives for accuracy.)
The point of my story is these CA generated expressions have issues of their own. The funny thing is my colleague was actually proud of the complexity of the problem, that he was clearly solving a really difficult problem because the algebra was so nasty. What I don't think he considered was if that algebra was actually computing the correct thing, was it doing so accurately, and was it doing so efficiently.
Had I been the senior person at the time on this project, I would have read him the riot act. His pride caused him to use a solution that was probably unnecessarily complex, without even checking that a finite difference based gradient was adequate. I'll bet we had spent perhaps a man-week of time to get this optimization running. At the very least, I would have counseled him to carefully test the gradient produced. Was it accurate? How accurate was it, compared to finite difference derivatives? In fact, there are tools around today that will also return an estimate of the error in their derivative prediction. This is certainly true for the adaptive differentiation code, (derivest) I've written in MATLAB.
Test the code. Verify the derivatives.
But before you do ANY of this, consider if other, better optimization schemes are an option. For example, if you are doing exponential fitting, then there is a very good chance you can use a partitioned nonlinear least squares (sometimes called separable least squares. I think that was the term used by Seber and Wild in their book.) The idea is to break the set of parameters into intrinsically linear and intrinsically nonlinear sets. Use an optimization that works on only the nonlinear parameters. Given those parameters are "known", then the intrinsically linear parameters can be estimated using simple linear least squares. This scheme will reduce the parameter space in the optimization. It makes the problem more robust, since you don't need to find starting values for the linear parameters. It reduces the dimensionality of your search space, so making the problem run more quickly. Again I have supplied a tool for this purpose, but only in MATLAB.
If you do use the analytical derivatives, code them to reuse terms. This can be a serious time savings, and may actually reduce the bugs, saving your own time. But then check those numbers!
codegen
package therein as it can generate compact and efficient C or Fortran code for each or all of the expressions automatically. $\endgroup$ – Pedro Aug 17 '13 at 20:21