Re: [pygsl-discuss] Frage bzgl. Nutzung Datentyp gsl_matrix mit pygsl

[Pierre S. <p.s...@gs...>]

On 07.09.2015 20:48, Stephan Brenner wrote:

Dear Stephan,


I split my answer in two parts:

1. Wrapping an object as a swig pointer:
     yes , you can do that, but then this object will be opaque to 
python. So

<Swig Object of type 'gsl_matrix *' at 0x7f26e1d95a80>

is some pointer that python will not manage. Now you would have to 
define element accessory functions
that return the element. Personally I think a mapping from numpy arrays 
to gsl matrices is most
of the time more convenient unless you have some huge matrices that are 
loaded from some other
source into gsl matrix.

As soon as you want to manipulate the data in python a direct mapping 
from numpy to gslmatrix
is much more convenient.


2. Using what pygsl provides:
     It is essential that you include init_pygsl(), because that loads 
the pygsi.init module, which provides
     the internal conversions functions from numpy to a gsl matrix. Your 
program will crash otherwise

     The warning (or error) of pygsl is due to a missing cast. 
init_pygsl checks that the correct API
     version is being used and that definitely fits in a void * pointer.

     Further the internal API needs to be updated to the newer numpy 
interface.



To sum up:
     If solution 1 or 2 is optimial for you depends on your application. 
Personally I prefer to have
     the data in python arrays as many scientific libraries are 
available which allow further processing
     of the data.

Sincerely yours
     Pierre


PS: Perhaps you can post a minimal example?




> Dear Pierre,
>
> thanks a lot for your fast and friendly reply. Unfortunately I did not make it.
> As advised I included the *.i files in the swig file as all as init_pygsl().
> At first, here in Ubuntu pygsl was not installed at the correct place I assume.
> For testing purposes I copied everything to /usr/include and now the files were found.
> But I got the following errors during the swig build process:
>
> stephan@haswell:~/Desktop/sqlite2money_so_swig_fortest$ ./build_swig.sh
> In file included from /usr/include/python2.7/numpy/ndarraytypes.h:1761:0,
>                   from /usr/include/python2.7/numpy/ndarrayobject.h:17,
>                   from /usr/include/python2.7/numpy/arrayobject.h:4,
>                   from /usr/include/pygsl/block_helpers.h:62,
>                   from talib_sqlite2money_wrap.c:2950:
> /usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
>   #warning "Using deprecated NumPy API, disable it by " \
>    ^
> In file included from /usr/include/pygsl/utils.h:4:0,
>                   from talib_sqlite2money_wrap.c:2949:
> talib_sqlite2money_wrap.c: In function ‘void init_talib_sqlite2money()’:
> talib_sqlite2money_wrap.c:5651:3: error: cast from ‘void*’ to ‘unsigned int’ loses precision [-fpermissive]
>     init_pygsl();
>     ^
> stephan@haswell:~/Desktop/sqlite2money_so_swig_fortest$
>
> At the next step I had another idea. I removed everything from my .i file. Compilation was now successful.
> In the c sources I added a function which creates a gsl_matrix and gives back a pointer to this object.
> In python the type is printed out as:
>
> <Swig Object of type 'gsl_matrix *' at 0x7f26e1d95a80>
>
> This object can be hand over to other c functions having a gsl_matrix as input. So this seems to be a way to
> create the needed gsl_matrix object. Now the only question which remain is how to access to elements inside
> this object from Python?
>
> Perhaps I do not understand the whole topic. Maybe this is exactly what the personal.i file should do?!
> Is there any working example how to access c based gsl shared object from python?
>
> Best regards so far...
>
> Yours Stephan
>
>
>
> Am 07.09.2015 um 15:47 schrieb Pierre SCHNIZER:
>> Dear Stephan,
>>
>>       I answer in English so that this information can be useful for non
>> german speaking users ..
>>
>> Mapping a pygsl array to gsl_matrix is not that difficult but one has to
>> take some subtle
>> differences into account:
>>
>> -- numpy counts strides in byte offsets
>> -- gsl counts strides in offsets of the basic type
>>
>> -- gsl vectors can have strides while gsl matrices are contiguous or a
>> submatrix
>>       of a contiguous matrix.
>>
>> If you want to roll your own, you have to take the differences above
>> into account.
>> Then take an numpy two dimensional array from user space and use
>> gsl_matrix_view to generate an appropriate gsl matrix structure.
>>
>>
>> Or you use what pygsl provides. Then in your swig file  import
>>
>> http://pygsl.cvs.sourceforge.net/viewvc/pygsl/pygsl/typemaps/gsl_block_typemaps.i
>>
>> Please do not forget to add
>> <snip>
>> %init %{
>>       init_pygsl();
>> %}
>> </snip>
>> in your swig file.
>>
>>
>> Please note that the respective search paths must be available for
>> swig and the C compiler.
>>
>> If you use setup.py you can use the _swig_Extension provided by pygsl.
>>
>> This should get you started. Happy to answer if there are more questions
>>
>> Sincerely yours
>>       PIerre

-- 
+---------------------------------------------------------------------+
   Pierre Schnizer  <p.s...@gs...>
   Telephon : +49 6159 71 1557
   Fax      : +49 6159 71 3099

GSI Helmholtzzentrum für Schwerionenforschung GmbH

Planckstraße 1
64291 Darmstadt
www.gsi.de

Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528

Geschäftsführung:
Ursula Weyrich
Professor Dr. Karlheinz Langanke

Vorsitzender des Aufsichtsrates: St Dr. Georg Schütte
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt
+---------------------------------------------------------------------+