Re: [eigen] two decisions to take

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

On Tuesday 04 September 2007 21:19:07 Schleimer, Ben wrote:
> 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.

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".

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).

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 &.

> > 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?

Eigen uses asserts, like
assert(v.is_a_vector());
I haven't yet written is_a_vector() but you get the idea. A Vector is a matrix 
that satisfies two conditions: cols()==1 and cols() is fixed at compile-time. 
I am allowing a matrix type to have fixed number of columns but variable 
number of rows.

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

So it's not a compile-time error, but close. And it gives a much nicer error 
message. Indeed, while compile errors in ET-enabled C++ code are horrendous, 
this will just output "assertion v.is_a_vector() failed at line... in file... 
in function ....(complete c++ function name here)". So I think it's quite OK.

>
> > 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.

I never said anyone would do "using namespace" in a header. I just mean, as 
you say, people will "using namespace" in their own cpp, and this will cancel 
for them the protection against pollution that was given by having things in 
a namespace.

Cheers,
Benoit

Attachment: signature.asc
Description: This is a digitally signed message part.