Re: [eigen] two decisions to take

["Schleimer, Ben" <bensch128@xxxxxxxxx>]

> 
> I agree with the operator^ for cross product, actually I proposed it one year 
> ago on #eigen for Eigen1 but someone objected. I don't remember what the 
> objection was.
> 
> If we go for operator^ for cross product, then I suggest operator| for dot 
> product. This is classical mathematical notation, especially in quantum 
> mechanics (Dirac's "bras" and "kets").

Ok. double zLen = x ^ y | n * 3 is difficult to read but possible to use. 
Sigh... maybe java's disallowing of operator overloading is the right idea. 

> 
> I assume that by "wedge" you mean: x wedge y = x * transpose(y). I disagree 
> with operator^ meaning wedge for vectors of size different from 3. If 
> operator^ means wedge for any size, then it should mean wedge for all sizes. 
> For size 3, wedge is different from cross, as wedge gives a 3x3 matrix while 
> cross gives a vector. So there would be a big consistency issue.

It was just an idea I read about awhile ago about generalizing the crossproduct to other
dimensions. But after looking at wikipedia about wedge products, maybe it's not really useful.
nevermind...

> Besides, Eigen2 will let you do x * transpose(y) for any vectors x,y and 
> obtain the result as an expression template. Indeed, Eigen2 treats vectors as 
> matrices with 1 column, so you will be able to apply transpose() to a vector 
> and get a "horizontal vector".

Do that include compile time check to make sure dot+cross+normalize only operates on matrices with
only one column?

> Of course everything in the Eigen namespace, as an additional measure. But I 
> don't regard this as an important protection against pollution, as many 
> people will want to "using namespace".

I think it's bad form to have "using namespace" in header files. In cpp files, it's useful and
normal. I guess good defensive programming requires both.

> 
> The main protection against pollution is that the global operators that I 
> define always take eigen-specific types as arguments. That, I think, is 
> really effective. At worst it makes the life of the compiler a bit harder 
> resolving overloading.

Ok...


> > We can always use setCross/^= vs. cross/^ to mean assignment operation vs
> > return value operation.
> 
> I don't think there is any use case. That kind of thing was very useful in 
> Eigen1 because we had to fight to avoid returning objects by value. In 
> Eigen2, we can do w = u ^ v without overhead. As to the case when one 
> actually wants to do u = u ^ v, I think that it is very uncommon.

True, I was mostly thinking of vec *= scalar; so ^= is probably not worth it.

Cheers
Ben