Boost logo

Ublas :

Subject: Re: [ublas] [bindings] Which Bindings should I direct my users to? Boost proper?
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2010-06-22 10:36:26


Thomas Klimpel wrote:

> Question: Which boost version (=quickbook version) should I use to
> generate the html? I suggest going with the latest released boost version
> (=1.43 currently), as that version won't at least not change daily.

I used trunk for this. Do other tools influence the generated html, like the
docbook version, installed Boost templates for this, etc.? IOW, perhaps the
boost version isn't the cause of different-looking results.

> Next I tried to address the issues recently reported by Peter Man
> (documentation can wait, you know). He had the crazy idea to include
> <boost/numeric/bindings/lapack.hpp> :-) So I generated a list of obvious
> incomplete generated code issues, and started to clean lapack/driver. Then
> I modified the code generator to be more confident when deducing workspace
> requirements from the code, which fixed 9 incomplete code issues in
> lapack/computational, but not all (the unfixed can be found in the
> attached fixme.txt).

Good stuff.

> Looking at the workspace issue for clapack, I noticed an unused "work"
> argument for the optimal_workspace and minimal_workspace cases (easy to
> fix by just modifying the template).

That's right -- this is done to keep code recompileable against both
backends (clapack, netlib lapack). May be cleaned up, though.

> But I decided to first try to reduce
> the size of the generated files by trying to address the perfect
> forwarding issue.

:-)

> But then somebody asked a question in the boost-mailing list about default
> arguments for templates, and David Abrahams answered that Boost.Parameter
> is able to solve this issue. So I tried to describe our problem (+current
> solution +attached syev.hpp to make it concrete) and expressed my doubts
> that Boost.Parameter would be able to help in this situation, but that I
> would be curious to learn about better solutions. Here is David Abrahams'
> answer: <http://lists.boost.org/Archives/boost/2010/06/168271.php>. So I
> immediately followed that suggestion in my next checkin.

Looks like a smart solution! I can not think of many problems that could
occur -- perhaps except with the instantiation of an adaptor?

[snip more good stuff]

> I have attached my current TODO list (fixme.txt), but I won't wait until
> it's empty before starting to write documentation.
>
> Summary of questions from above:
>
> - Which boost version (=quickbook version) should I use to generate the
> html?

That's up to us :-). Could be current (1.43) or trunk. What Boost version do
you use for unit testing? I tend to keep a copy of Boost trunk for this
stuff; I don't mind checking out a release branch for this. But perhaps this
doesn't solve the problem of different-looking results.

> - Do you approve the new name "VectorView" for "Vector" arguments that
> support general strides?

So, a VectorView is one that supports strides, and a Vector is one that
doesn't? Hmm. Both may be views, e.g., a contiguous column or row. What
about "Vector" (=generic) and "ContiguousVector" (=one with stride 1), isn't
that more precise?

> - Should we omit nearly all overloads, because they are no longer
> important now?

I don't see any problem with this.

> - Do you approve the sections for "Driver Routines", "Computational
> Routines" and "Auxiliary Routines" for lapack and "Level 1 BLAS", "Level 2
> BLAS" and "Level 3 BLAS" for blas in the Reference documenation?

Yes. A good and clear reflection of the layout of those libraries (and the
directory structure :-)).

> - How often should the generated html be checked in? I would tend to
> update it only very infrequently, as some GUID's always change and cause
> the checkin to be really huge.

I agree, another alternative could be if we could upload it into some web
space somewhere. Svn repository access isn't the best tool for this job
IMHO.

I will see if there's something I can fix immediately in the fixme file.

Cheers,

Rutger