On Friday 27 February 2009 09:42:45 Klaas Gadeyne wrote:
> [...]
>
> >> 2/ Isn't this something we should try and get in upstream
> >> implementations. After all, BFL wants to provide wrappers and leave
> >> matrix functionality in matrix libraries (Herman, this must sound like
> >> good sixties music in your ears
> >>
> >> :-)
> >
> > Certainly we do. But, recently I'm not really satisfied with our
> > boost-choice as a matrix library. Boost is far from real-time and uses
> > allocations in it's calculations.
>
> Any idea wether lti/newmat is better (in that respect)?
For lti no. Newmat needs to be checked.

> > I ran some performance checks on our filter examples and from that I
> > learned that the major part of computation time is spend in doing matrix
> > calculations. Therefore, me and Herman Bruyninckx are considering
> > switching to eigen2 matrix library. The only thing we lack is time....
>
> Enter gSoc?
Yes. We are negotiating this.
> Is KDL using a fixed matrix library (eigen2?)?
Not yet. But Ruben (the developer) is also considering choosing eigen2 as the
matrix library.
We had a quick check and it looks very promising. They give no guarantees to
be allocation free and some are present in the code but we could contribute in
improving this aspect.

> >> 3/ Since it's committed, you probably could change the status to
> >> resolved (unless you were anticipating annoying remarks from retired phd
> >> students, that is :-)
> >
> > I was expecting remarks, but that was not the reason I didn't change the
> > status to resolved.
> > I didn't change it since the title is quit general (see mail subject) and
> > I only make special case calculation for determinant and inverse in the
> > boost case. So any other special case calculations can still be
> > implemented (also for lti and newmat implementations).
>
> Ah, I see. I though that maybe the other libraries realised these
> special cases themselves when I saw the patch.
ok.

> > Maybe I should reveal underlying reason for this sudden (and unexpected)
> > change. In an application I'm currently working on, the inverse of a 2x2
> > matrix (boost) fails due to a failure in the LU-factorization of boost.
> > It's completely unclear to me why it fails since there is no problem at
> > all with the matrix.
> > So a fast solution was to provide a special case implementation of the
> > inverse ;).
>
> Just changing the matrix library was not a (faster) option?
I need some extra functionality from boost in my application so changing the
matrix library was not really an option.

Tinne

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

_______________________________________________
I hereby promise not to top-post on the
BFL mailing list
BFL [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Fri, 27 Feb 2009, Klaas Gadeyne wrote:

> [...]
>>> 2/ Isn't this something we should try and get in upstream implementations.
>>> After all, BFL wants to provide wrappers and leave matrix functionality in
>>> matrix libraries (Herman, this must sound like good sixties music in your
>>> ears
>>>
>>> :-)
>> Certainly we do. But, recently I'm not really satisfied with our boost-choice
>> as a matrix library. Boost is far from real-time and uses allocations in it's
>> calculations.
>
> Any idea wether lti/newmat is better (in that respect)?

A lot of allocations behind the screens...

>> I ran some performance checks on our filter examples and from that I learned
>> that the major part of computation time is spend in doing matrix calculations.
>> Therefore, me and Herman Bruyninckx are considering switching to eigen2 matrix
>> library. The only thing we lack is time....
>
> Enter gSoc?
> Is KDL using a fixed matrix library (eigen2?)?

Ruben (the KDL maintainer) is also looking into Eigen2, and he and me begin
to like it more and more. For me personally, the _major_ reasons to like it
are:
- it can be checked not to use any runtime allocations
- it is now firmly established as _the_ math toolbox for a large scale
project such as KDE
The major reason _not_ to like it is:
- it's only C++ templates, which is not easy.
But the latter problem is traditionally overcome by having only the core
developers being confronted with this complexity, while nothing of it shows
through at the user level APIs... (Except for maybe a "configuration" state
in a state-based template of using BFL code...)

>>> 3/ Since it's committed, you probably could change the status to resolved
>>> (unless you were anticipating annoying remarks from retired phd students,
>>> that is :-)
>> I was expecting remarks, but that was not the reason I didn't change the
>> status to resolved.
>> I didn't change it since the title is quit general (see mail subject) and I
>> only make special case calculation for determinant and inverse in the boost
>> case. So any other special case calculations can still be implemented (also
>> for lti and newmat implementations).
>
> Ah, I see. I though that maybe the other libraries realised these
> special cases themselves when I saw the patch.
>
>> Maybe I should reveal underlying reason for this sudden (and unexpected)
>> change. In an application I'm currently working on, the inverse of a 2x2
>> matrix (boost) fails due to a failure in the LU-factorization of boost. It's
>> completely unclear to me why it fails since there is no problem at all with
>> the matrix.
>> So a fast solution was to provide a special case implementation of the inverse
>> ;).
>
> Just changing the matrix library was not a (faster) option?
>
> Klaas

Herman
_______________________________________________
I hereby promise not to top-post on the
BFL mailing list
BFL [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/bfl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm