2. Design of the PyGSL interface

The GSL library was implemented using the C language. This implies that each function uses a certain type for the different variables and are fixed to one specific type. The wrapper will try to convert each argument to the approbriate C type. The PyGSL interface tries to follow it as much as possible but only as far as resonable. For example the definition of the poly_eval function in C is given by

double gsl_poly_eval( const double C[], const int LEN, const double X)

The corresponding python wrapper was implemented by

poly.poly_eval( C, x)
as the wrapper can get the length of any python object and then fill the len variable. The mathematical calculation is performed by the GSL library. Thus the calculation is limited to the precision provided by the underlying hardware.

Default arguments are used to allocate workspaces on the fly if not provided by the user. Consider for example the fft module. The function for the real forward transform is named

int gsl_fft_real_transform( double DATA[], size_t STRIDE, size_t N, const gsl_fft_real_wavetable * WAVETABLE, gsl_fft_real_workspace * WORK )

The corresponding python wrapper is found in the fft module called real_transform

real_transform( data, [space, table, output])
The wrapper will get the stride and size information from the data object provided by the user. If space or table are not provided, these objects will be generated on the fly. As the GSL function applies the transformation in space, an internal copy is made of the data and only then the object is passed to the GSL function. If an output object is provided the data will be copied there instead. PyGSL will always make copies of objects which would be otherwise modified in place.