Re: [eigen] two decisions to take |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] two decisions to take*From*: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>*Date*: Wed, 5 Sep 2007 08:35:24 +0200

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

**Follow-Ups**:**Re: [eigen] two decisions to take***From:*Schleimer, Ben

**References**:**Re: [eigen] two decisions to take***From:*Schleimer, Ben

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] two decisions to take** - Next by Date:
**[eigen] Eigen2 initial commit** - Previous by thread:
**Re: [eigen] two decisions to take** - Next by thread:
**Re: [eigen] two decisions to take**

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