Boost logo

Ublas :

Subject: Re: [ublas] GSL support
From: Kraus Philipp (philipp.kraus_at_[hidden])
Date: 2012-06-21 15:13:19


Hi Rudger,

thanks a lot for these informations. I need some days to take a look into the scripts and GSL calls

Phil

Am 20.06.2012 um 10:30 schrieb Rutger ter Borg:

> On 2012-06-05 17:16, Philipp Kraus wrote:
>>
>> I would ask you again, if there is any how-to or tutorial in which way I
>> can
>> create an interface / binding for the GSL calls. Can you send me some
>> information for the automatic detection and the python app to parse the
>> header files?
>>
>> Thanks
>>
>> Phil
>>
>
> The python apps are in libs/numeric/bindings/tools. There are two generators, blas_generator.py and lapack_generator.py. They require a couple of source packages to get up and running (look in the python files for lapack_src_dir etc.). I just wanted to test them against the latest Lapack version in Debian (3.4.1), but unfortunately the lapack sources have changed their commenting style quite drastically. This means the parser will have to be updated to handle the new formatting of comments. To good side is that it looks like it can be parsed by doxygen.
>
> The generators collect API calls, group those on value type, and insert the appropriate bindings-traits and asserts to glue everything together, and finally write out a bunch of files.
>
> In the python files you may find references to "level 0", "level 1", etc., these refer to
>
> Level 0: detail namespace overloads
> Level 1: classes calling those detail namespace overloads
> Level 2: free functions calling the classes
>
> Some code shared between BLAS and LAPACK ended up in netlib.py.
>
> Any way, to get support for GSL up and running, and have it in similar style of the rest of the bindings, make sure you have the sources
>
> $ cd tools
> $ apt-get source gsl (or just download and unzip)
>
> I see the GSL also provides a BLAS implementation; I guess we should add support for GSL backend to the BLAS generator. It is relatively straightforward to add this.
>
> The parser should go through the entire gsl source code base, automatically collect information about the gsl_ API, group on value type, and write out some nice binding files.
>
> I could help a bit more if you could provide an example handwritten binding to a GSL function, and
>
> * what are the bindings supposed to automatically fill-in?
> * what are the options to GSL (like upper etc. in BLAS)?
> * should the FFT interface be compared with other backends and be taken apart?
> * etc.
>
> I hope this helps.
>
> Cheers,
>
> Rutger
>