Re: [eigen] alpha6!

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

Hi Gael,
   I agree it's faster in the beginning to write your classes so the different types are easily convertible (hey, Rotation2D can work just like a scalar!) but in the long run, it's bad for the API because the types ARE not the same. As I said before, the user and compiler will get confused.

It's only a couple of extra lines to implement
operator+-*/ etc. and it's only an extra word to use toScalar() instead of operator Scalar().
It'll make the API clearer in the long run because it'll be clear to the user which operations are usable with Rotation2D and which aren't

operator=(Scalar) and Rotation2D(Scalar) aren't problems because no type inferencing is required by the compiler.

All of the above applies to Quaterion, angleAxis, and Matrix

Cheers
Ben




--- On Fri, 8/15/08, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

> From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
> Subject: Re: [eigen] alpha6!
> To: eigen@xxxxxxxxxxxxxxxxxxx
> Date: Friday, August 15, 2008, 8:41 AM
> Hi,
> 
> thanks for the feedback. For the same reason than you I
> usually don't
> like the use of such casting operators. However I think
> here they are
> quite safe. Actually the main question is whether or not we
> want to
> allow automatic conversion between each rotation
> representation or not
> ? Automatic conversion between Quaternion and AngleAxis
> also exist by
> mean of constructors and operator=(). Here I used the cast
> operator
> because I initially wanted to separate the Core and
> Geometry module as
> much as possible.
> 
> Currently you can write:
> 
> Matrix3f rotmat;
> Quaternionf q;
> rotmat = AngleAxisf(alpha,Vector3::UnitX());
> q = AngleAxisf(alpha,Vector3::UnitX());
> rotmat = q;
> 
> I cannot think to any case where this would be dangerous, 
> and if you
> want to be more explicit in your code you can still write:
> 
> rotmat =
> AngleAxisf(alpha,Vector3::UnitX()).toRotationMatrix();
> rotmat = Matrix3f(AngleAxisf(alpha,Vector3::UnitX())));
> q = Quaternion(AngleAxisf(alpha,Vector3::UnitX()));
> rotmat = q.toRotationMatrix();
> 
> If someone is still strongly against such automatic
> conversion then I
> agree to remove the cast operators, the operator= and keep
> only
> explicit constructor.
> 
> 
> About the operator Rotation2D::operator Scalar(), again I
> think this
> one is really safe since Rotation2D is nothing else than a
> Scalar with
> a function toRotationMatrix() and slerp(). The idea of this
> cast
> operator is to be able to write:
> 
> Rotation2D<float> rot = M_PI/2;
> rot = rot * 0.25;
> 
> without redefining all arithmetic operators in Rotation2D,
> that's it.
> 
> 
> Gael.
> 
> 
> 
> 
> 
> On Wed, Aug 13, 2008 at 10:43 AM, Schleimer, Ben
> <bensch128@xxxxxxxxx> wrote:
> > Wow Benoit,
> >   I have to say that I am extremely impressed with
> Eigen2 and the cleanliness of the api. WOW! I'm really
> looking forward to using it in my next krita plugin, (when I
> get a break from work...) and am really excited to do so. My
> only issue is the usage of the operator Matrix3f() in
> AngleAxis and Quaterion and operator Scalar() and others in
> Rotation2d. The toMatrix() is clearer and less error prone
> IMHO.
> >
> > Also, I hope you add the performance benchmarks as
> examples to the wiki.
> > They would be good examples to work from No?
> >
> > Cheers
> > Ben
> >
> >
> >
> >
> > --- On Mon, 8/11/08, Benoît Jacob
> <jacob@xxxxxxxxxxxxxxx> wrote:
> >
> >> From: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>
> >> Subject: [eigen] alpha6!
> >> To: eigen@xxxxxxxxxxxxxxxxxxx
> >> Date: Monday, August 11, 2008, 9:23 PM
> >> Hi List,
> >>
> >> Eigen 2.0-alpha6 is released!
> >>
> >> Wiki: http://eigen.tuxfamily.org
> >> Tarball:
> >>
> http://download.tuxfamily.org/eigen/eigen-2.0-alpha6.tar.bz2
> >> API: http://eigen.tuxfamily.org/api/
> >>
> >> It is now time for eigen1 apps to port to eigen2,
> as it now
> >> supports
> >> essentially all what eigen1 did.
> >>
> >> The changes since alpha5 are huge, there are 160
> commits
> >> since alpha5, the
> >> sloccount is now 10975 (up from 6143 in alpha5),
> so I'm
> >> not going to list
> >> them all here, here is just an overview:
> >>
> >> - huge benchmarking and optimization effort by
> Gael. We now
> >> often beat the
> >> established "big iron" libraries on
> their own
> >> ground, which is, standard
> >> algorithms on large matrices:
> >>
> http://eigen.tuxfamily.org/index.php?title=Benchmark
> >>
> >> - huge vectorization improvements, resulting in
> much more
> >> vectorization, and
> >> much cleaner, faster, extensible source code.
> >>
> >> - Gael made the Geometry module (with homogeneous
> >> transforms, rotations,
> >> quaternions etc).
> >>
> >> - Gael started the Sparse module, still
> experimental and
> >> incomplete (probably
> >> not for 2.0), but showing amazing performance
> already.
> >>
> >> - I made the LU module (in alpha5 it was just a
> stub).
> >>
> >> - I reworked the API for cwise ops, and
> reimplemented Swap
> >> so it automatically
> >> benefits from the vectorization, unrolling, and
> traverses
> >> arrays only once.
> >>
> >> - Gael rewrote the partial reduction stuff.
> >>
> >> - I added a little demo, 'mandelbrot', a
> fractal
> >> viewer, demonstrating how
> >> Eigen can be used purely as a vectorization
> library.
> >>
> >> - I added a quick and dirty Regression module
> adapted from
> >> eigen1. It will
> >> change before 2.0, though.
> >>
> >> - we worked on reducing significantly compilation
> times.
> >>
> >> - many many improvements all over the place by
> both of us.
> >>
> >>
> >> I surely forgot a ton of things!
> >>
> >> Now I must make a pause to dedicate myself to my
> new
> >> postdoc position at the
> >> University of Toronto. I'll just be doing what
> is
> >> needed for KDE 4.2, KOffice
> >> 2.0, Avogadro 1.0, OpenBabel 3.0 (to name a few
> projects
> >> which should be
> >> users of eigen2 in the near future). I think that
> Gael is
> >> going to be busy
> >> too with his new position and even more so now
> that
> >> he'll be living in the
> >> same city as his girlfriend again :)
> >>
> >> So, to anyone lurking here -- now's a great
> time to
> >> step up and join us! We'd
> >> be happy to mentor newcomers. Among the jobs you
> could
> >> start with, you could
> >> write SVD decomposition, improve the
> QR/eigenvalues stuff
> >> in some way, help
> >> with the Sparse module, revive AltiVec
> vectorization, help
> >> vectorize more
> >> parts of the code (such as Redux.h and Visitor.h),
> and the
> >> list goes on...
> >> (yes, we should update the TODO).
> >>
> >> Cheers,
> >> Benoit
> >
> >
> >