I'm new to Eigen and although it looks great, I'm wondering what the logic behind using a.cwise().log() instead of just log(a). Mathematics, and many other libraries (e.g, http://scythe.wustl.edu/) follow the op(a) convention even if method calls are more in line with the underlying language (C++). I have found this leads to much cleaner looking numeric code. Moreover, all of these function operator elementwise, so cwise() is redundant.

I assume it is past the point where any of this matters, but am I missing something?

There are two different issues in question.

The first one is global functions vs method. As you guessed, we chose the later option because it is more object oriented (no namespace pollution, etc). If this really annoys you, you still write a small module provide global functions as wrappers around a few MatrixBase and Cwise methods (dot, cross, pow, log, abs, sin, cos, tan, etc). This leads us to the second issue: how to name those global function. Indeed, it is not hazard we put some of these function in a Cwise proxy object: the goal was to make it clear it works coefficient-wise. For instance, think about pow(mat,2) : should it return mat * mat or mat.cwise().pow(2) ? So I guess, it is clearly not a good idea to directly reuse the standard function names to perform coeff-wise operations, but instead add a short prefix, e.g.: cwiseLog, cwisePow, ...

In case you write such wrappers, I'll be happy to include them in a new module. Here is a full example (not tested):

template CwiseUnaryOp::Scalar>, Derived>
cwiseLog(const MatrixBase& x) {
return x.cwise().log();
}

Indeed, the "coefficient-wise log" is not the same as the "matrix log" ! The latter, defined only for positive definite matrices, is computed by diagonalizing the matrix and taking the logs of the eigenvalues.

I see the argument. I would say vectorize all the math.h functions, and have special matrix versions if there are objectwise equivalents.

It depends on where you're coming from. I'm coming from the matlab, R, numpy type environment and just need to speed up a few small algorithms. Here polluting the global namespace is no big deal and makes the static code more consistent with the dynamic syntax. On the other hand, for large projects the current solutions is probably wise.

Scythe is designed with this goal in mind, but I suspect has much poorer performance.

On another note, in terms of logical organization for statisticians, Stata's new "Mata" matrix language is very clean: http://www.stata.com/help.cgi?mata. Also, I see there are discussions about special matrix types. R just added a new matrix library that has thought a lot of this through and documented their process pretty thoroughly. It is now included in the R base install: http://cran.r-project.org/web/packages/ ... index.html. There may be some good ideas there.

I'll look more closely at Eigen though.