[Swig-devel] python and numpy pyfragments.swg

[Kris Thielemans]

Hi

I'm trying to get numpy support into our STIR library using SWIG and intend
to use the SWIG files supplied with numpy (or is there a better option?).
I'm running into the issue mentioned on

http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#numpy-arr
ay-scalars-and-swig

i.e. when having a numpy scalar, the current SWIG converters don't recognise
it. The numpy folks supply a pyfragments.swg to add fragments
SWIG_AsVal_frag(long) and SWIG_AsVal_frag(unsigned long):

https://github.com/numpy/numpy/blob/master/tools/swig/pyfragments.swg

There is no fragment for double though. It's easy enough to add one, but I
have a few questions:

- to me, it seems terribly unsafe (i.e. non-maintainable) to copy the
fragment code from pyprimtypes.swg and then add some numpy specific to it.
It would be far better to be able to call the "original" function, and then
do numpy checks if the "original" SWIG_AsVal failed. Is that possible?

- There is no SWIG_AsVal(float) in pyprimtypes.swg, as it relies on
conversion from double to float. This works, but I guess for numpy can load
to numpy::float32->double->float conversions (with lots of overhead along
the way). I don't mind too much, but is there an easy way around that?

- there is an open issue about a memory leak in the current numpy
pyfragments.swg, see https://github.com/numpy/numpy/issues/5181. I think
that concern raised is correct and intend to add the Py_DECREF as suggested.
I'm ending up with code like

if (PyArray_IsScalar(obj,Double))
{
PyArray_Descr * descr = PyArray_DescrNewFromType(NPY_DOUBLE);
PyArray_CastScalarToCtype(obj, (void*)val, descr);
Py_DECREF(descr);
return SWIG_AddCast(SWIG_OK);
}

See attached pyfragments.swg.

Any comments?

Apologies if you think this should go to the numpy list, but I'm hoping for
good response here!

Kris

[William S Fulton]

On 18 October 2015 at 10:15, Kris Thielemans

Post by Kris Thielemans
Hi
I'm trying to get numpy support into our STIR library using SWIG and intend
to use the SWIG files supplied with numpy (or is there a better option?).
I'm running into the issue mentioned on
http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#numpy-arr
ay-scalars-and-swig
i.e. when having a numpy scalar, the current SWIG converters don't recognise
it. The numpy folks supply a pyfragments.swg to add fragments
https://github.com/numpy/numpy/blob/master/tools/swig/pyfragments.swg
There is no fragment for double though. It's easy enough to add one, but I
- to me, it seems terribly unsafe (i.e. non-maintainable) to copy the
fragment code from pyprimtypes.swg and then add some numpy specific to it.
It would be far better to be able to call the "original" function, and then
do numpy checks if the "original" SWIG_AsVal failed. Is that possible?

Fragments are designed to be overriden, similarly for typemaps. This
is to give users maximum flexibllity over code generation. Copying
typemap or fragment code for the override, then tweaking to meet your
own needs is reasonable in my opinion. If you want to re-use the code
supplied by SWIG, a better approach would be to override the typemap
and inside the typemap call the original SWIG fragment and add in
extra Numpy specifics. Not sure if that will work, but might be worth
investigating. if there is a need to modify the default typemaps or
fragments, then they will of course require maintenance, you can't
really avoid that. Using $typemap can be considered for named
typemaps, eg:

%typemap(in) long abc %{
$typemap(in, long) // generates default code from %typemap(in) long
// additional code
%}
void foo(int abc);

I doubt that would work in this case though.

Post by Kris Thielemans
- There is no SWIG_AsVal(float) in pyprimtypes.swg, as it relies on
conversion from double to float. This works, but I guess for numpy can load
to numpy::float32->double->float conversions (with lots of overhead along
the way). I don't mind too much, but is there an easy way around that?

Provide typemaps to generate your preferred code.

William

------------------------------------------------------------------------------