Re: [eigen] two decisions to take

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

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/