Hi,

I would like to know a bit more about the reasoning behind the matrix.cwise().ufunc() design. For example

m.cwise().cos()

is a lot more cumbersome than

cos(m)

especially in long expression which involve lots of ufuncs.

Is the reason speed, or the possibility of scalar type customization, or something else? What exactly is not possible with cos(m) that is possible with m.cwise().cos()?

Cheers,
G.

There are 2 design decisions here.

1) Why cwise(), why not just m.cos()

That's because that would be very ambiguous. m.cos() could mean either that cos is applied coefficient-wise, or it could mean the actual matrix cos function that is a different thing (the latter can be defined e.g. with the power series m.cos() = identity - m^2/2 + m^4/24 - m^6/720 + ...)

2) Why member method m.cos() and not global function cos(m)

That's purely a matter of taste, we chose to go for member functions whenever possible, that's all.

bjacob wrote:There are 2 design decisions here.

1) Why cwise(), why not just m.cos()

That's because that would be very ambiguous. m.cos() could mean either that cos is applied coefficient-wise, or it could mean the actual matrix cos function that is a different thing (the latter can be defined e.g. with the power series m.cos() = identity - m^2/2 + m^4/24 - m^6/720 + ...)

2) Why member method m.cos() and not global function cos(m)

That's purely a matter of taste, we chose to go for member functions whenever possible, that's all.

Thanks for your very fast reply.

I hear a mathematician speak . I thinks scientists in most other fields would special-case the matrix version of the ufuncs and make the coefficient version the default. This is how it's done in Matlab, numerical python, etc. In any case, as you mention in the docs, Eigen allows to include add-ons to the MatrixBase which allow to create shortcuts for sin(), cos(), etc. I do expect, however, that quite a number of users that intensively use these ufuncs are doing this.

GeorgeKnight wrote:I hear a mathematician speak . I thinks scientists in most other fields would special-case the matrix version of the ufuncs and make the coefficient version the default. This is how it's done in Matlab, numerical python, etc. In any case, as you mention in the docs, Eigen allows to include add-ons to the MatrixBase which allow to create shortcuts for sin(), cos(), etc. I do expect, however, that quite a number of users that intensively use these ufuncs are doing this.

Having come to eigen from a matlab background, from my perspective, this is one of the advantages of eigen over matlab, not a disadvantage:

I think matlab is terribly inconsistent in this matter. Particularly when it concerns multi-dimensional matrices in combination with non-builtin functions, there's no real common practice how to treat such calls. It's often unclear whether a function is executed per row, per column, per coefficient, or something else entirely (not to mention the confusion surrounding the occasional swapping of the first two indexes of a "matrix" in matlab). Many functions (including basic indexing) are "smart" in that they adapt to either row-based, column based or coefficient-based usage depending on the shape of the argument, which commonly implies a hefty performance penalty and odd N=1 edge cases where things break down and "work differently". Matlab has a great diversity of useful library functions and a lot of history and thus polish; but in terms of syntax and consistency I don't think it's a good example to follow.

cos(m) and m.cwise().cos() are of similar complexity; but the latter communicates to the reader clearly what's going on whereas the former is ambiguous (and can't be used consistently for all functions).

Is there a simple typedef that one can use such that the array operations are used instead of the Matrix ones by default?

I'd like to use Eigen as a much lighter weight replacement for Blitz++.

Thanks,

John

That couldn't be achieved by a typedef. Instead, what you're after is:
http://eigen.tuxfamily.org/dox/Customiz ... MatrixBase

Well, this is not as easy because, e.g., it is not possible to redefine the behavior of operator* to perform a coeff wise product. Actually, I think such a feature is something that is really missing in Eigen. I remember at the beginning of Eigen2 I've proposed a couple of cumbersome solution to that issue, but now I think I have a good proposal, let's discuss it on the mailing list...