Re: [eigen] alpha6!

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

hi,

alright, I agree with you. FYI, in rev 849039 those cast operators
have been replaced by explicit constructors and respective operator=.
Moreover I have to admit I was entirely wrong when I said Rotation2D
is "just a scalar". For instance the operator* between two Rotation2D
is actually implemented as a "+" between 2 scalars ...This has been
fixed in the same revision as well.

gael.

On Fri, Aug 15, 2008 at 8:36 PM, Schleimer, Ben <bensch128@xxxxxxxxx> wrote:
> 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
>> >
>> >
>> >
>
>
>