I wanted to calculate numerical derivatives and I found the numDeriv package in R and loaded it. It seems like a pretty serious effort and seems to work fine. I just have one problem . . .

My problem is the ordering of the arguments in the function call. For example, the “hessian” function is called like this:

hessian (func, x, method=”Richardson”, method.args=list(), …)

where “func” is the function to be differentiated, x is the vector representing the point where you evaluate the function, the next two arguments involve the method of computing the derivative, and “…” represents the additional arguments to be sent to “func” (for example, if “func” is a log-likelihood function, “…” would include the data being passed to the function.

The problem is that I have to specify those damn method arguments. For example, here’s a function call:

d2.log.lik <- hessian (log.lik, method="Richardson", method.args=NULL, mode, x,y,n) It would be better to change the ordering of the arguments, as follows: hessian (func, x, ..., method="Richardson", method.args=list()) That way, you could specify the arguments in "..." without having to specify the "method" arguments. That is how things are done with the "optim" function. Reply from the authors of the package

P.S. Ravi Varadhan and Paul Gilbert were kind enough to answer some of my questions. One problem was that I had a variable called “x”, which was the name of one of the arguments to their function. Paul wrote:

It sounds like you would like something like

d2.log.lik <- hessian (func=log.lik, x=mode, x, y=y,n=n) so your mode object gets matched to hessian's x argument and then the x,y,n get passed as ... . Unfortunately, I think x gets positionally matched with hessian's method argument in this case. You probably do have to rename the arguments to your function. Since hessian does not have a mode argument, I think mode=mode forces this argument to be matched with ... in hessian. Unfortunately there is not really a perfect way to do this. In some other code I use and argument func.args=list() which gets passed along to func, but that turns out to be cumbersome most of the time. It would be possible to have ... earlier in the argument list, at least in S3 but it may be more of a problem in S4. I think that would make it much more difficult to change the defaults without specifying the whole list of default values. Specifying only the ones you want to change turns out to be fairly convenient. In general I find specifying ..., other than at the end, should be avoided unless absolutely necessary. The problems are that things you do not intend can get matched with ..., especial when you are down a few calls in the stack, and debugging becomes really difficult. In addition there is the small problem that partial argument matching does not work after the ..., but I don't think of that as a real problem. It is rarely necessary to have ... earlier in the argument list. It does not seem certain that it would solve things in this case, and may actually make some situations worse.