|
|
Ublas : |
Subject: Re: [ublas] Snapshot 20081116
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-11-23 10:35:09
Rutger ter Borg wrote:
> Exactly. I am interested in helping. I've using it since one of the earliest
> releases, I've written a library around it (see
> http://www.terborg.net/research/kml/), and I've have been promoting the use
> ever since.
Welcome aboard :-)
If you want write access to the sandbox repository, you should follow the guidelines under
https://svn.boost.org/trac/boost/wiki/BoostSubversion
> > For the short
> > term, I think it is more important to address the "backlog", i.e. review
> > and integrate existing user patches (and add tests for the corresponding
> > functionality) and add badly missing functionality (like full support for
> > 64-bit platforms).
>
> Ideally, we could decide on where the bar is for submission for review, so
> we can work towards that.
The problem is not the quality of the patches, it's just the time to review and integrate them.
> I think if we could get it up to the quality to
> get it accepted into Boost, its user base could grow and thereby increasing
> the speed of development.
I guess it's more the amount of available developer time than the size of the user base that determines the speed of development. On the other hand, if "math" libraries like eigen, GLAS, MTL4, tnt or uBLAS would adapt the numeric bindings library instead of rolling their own bindings, they might devote some of their available developer time to it. (Currently, only GLAS and uBLAS have adapted the numeric bindings library.)
> Is there an overview or bucket that contains those patches and/or TODO list?
Andreas was the one who collected the patches, so he should know how many are still missing. I know of the following two that must still be reviewed and integrated:
Vardan Akopian:
http://lists.boost.org/MailArchives/ublas/2006/10/1435.php
gbsv.hpp
Jesse Manning:
http://lists.boost.org/MailArchives/ublas/2007/08/2274.php
lapack/gels.hpp
lapack/gelss.hpp
lapack/gelsd.hpp
test/ublas_gels.cpp
test/ublas_gelss.cpp
test/ublas_gelsd.cpp
test/convenience.h
The files should be taken from
http://mathema.tician.de/software/boost-bindings
because they have already matured a bit there.
I will probably work on Vardan Akopian's patch next weekend. There were some discussions about it lately, so that I already started to review it, in a certain sense.
I should definitely start another thread to describe the current issues on 64-bit platforms and the ideas of how to address them. Because of lack of time, I often don't even know whether it is the numeric bindings library that is causing the problems, or the interoperability between fortran and c++ compiler. When I use g77 to compile lapack and gcc-4.2 to compile the c++ code using the bindings, I seem to be unable to get the value returned from a fortran FUNCTION. I might try compiling lapack with gfortran instead, but I didn't find the time to do this. When I said it would be important to address the "backlog", I was mostly referring to the fact that I don't even spend enough time do these "trivial" things.
Karl Meerbergen wrote:
> Kresimir, Toon and I have found several inconsistencies. The library
> needs tidying up. Also, the BLAS and LAPACK bindings should be
> completed, since many routines do not have a binding, but this is a lot
> of work. I do not believe this is going to happen soon.
This is another point on a potential TODO list. I can confirm the above statement, but I don't have their actual list of inconsistencies and missing bindings. I sort of have my own list of missing functionality that I plan to add and inconsistencies that I plan to fix. However, because I know that it won't happen soon, I didn't bother to write it down.
> Would it be an idea to use Boost's trac wiki/ticketing facilities for this?
Good question. I don't know whether not yet released boost libraries are allowed/expected to use these facilities. But there are wikis for the google summer of code projects
(https://svn.boost.org/trac/boost/wiki/soc), so it should be possible to set up a wiki page there. There is also the boost user wiki web
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl
but it doesn't really look actively maintained anymore.
> Also, I think it will be great if the enormous effort of,
> e.g., LAPACK, ATLAS, and others like it, doesn't have to be replicated in
> uBLAS before it can be used.
That's true, but I also hope that LAPACK/ATLAS will not be the last word on numerical linear algebra. I'm still curious what will come out of projects like FLAME, GLAS or MTL4. But I agree that it's better to have one numeric bindings library that really works instead of a many half-baked bindings for each "math" library.
> I think the numeric bindings will work with any vector and/or matrix type
> that adheres to certain concepts (e.g., like those defined by uBLAS),
> doesn't it? In other words, making it an independent library is something
> that's not infeasible.
One has to write the corresponding traits for a given vector and/or matrix type to make it work with the numeric bindings library. Apart from that, the numeric bindings library is limited to single or double precision real or complex numbers. And it is in fact even more limited, because matrices have to be column major to be usable with lapack, the restrictions for banded matrices and sparse matrices being even more severe. So block storage or distributed matrices are totally out of reach.
That said, it might make sense to try to make the library more independent uBLAS. One direction would be to try to convince the MTL4 or eigen developers to adapt the library. Another thing that might make sense would be to provide simple wrappers for the concepts modeled by the traits (together with the corresponding traits for the wrappers). I currently have other priorities, but if you like...
Regards,
Thomas