Re: [eigen] two decisions to take

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

Hey Benoit,

> 
> Operator overloading is our only chance to get infix notation, which you were 
> asking for in your previous e-mail :) I think the best thing would be if C++ 
> allowed us to define new operators (instead of just overloading existing 
> ones) so we could allow "x dot y", i.e. the operator is "dot".

I was think of infix as x.dot(y) as opposed to prefix which is dot(x,y).
Whether the methods are named or are overloaded operators doesn't matter.
Actually it would be very nice if for every overloaded operator, there is the named version too
just so if we want our expressions to be clearer, it's possible.

> By the way, I checked C++ operator priority and x ^ y | n will work, as well 
> as n | x ^ y, because operator| has lower priority (it's almost lowest in the 
> priority list, which is nice for dot product).

Yippy! Fun with priorities. Just the thing to make or break eigen2. We need named methods...

> 
> On and I just thought: x^y|n is just the determinant of the 3x3 matrix whose 
> columns are x,y,n. So this leads to the idea: shall we add an operator to 
> group together matrices horizontally (or vectors, seen as matrices with 1 
> column) side-by-side and return a wider matrix (expression) ? I'd suggest 
> calling that operator&, to follow LaTeX notation of matrices. So instead of 
> x^y|n, you could do: det(x & y & n). What's your opinion ?
> 
> In that case we could do the same for vertical grouping but I don't know which 
> operator to use, maybe operator&& ? Not much choice here, as it needs to have 
> lower priority than &.

Sounds like something to leave until someone asks for that feature. They both sound useful but
outside of tensor operations, I can't imagine what it could be used for.

> 
> The point is that is_a_vector() will always evaluate at compile-time. So the 
> assert will evaluate as assert(0) or assert(1).

Cool... That's very interesting...

Cheers
Ben