Fwd: numpy.i and std::complex
Hello, I was very excited to learn about numpy.i for easy numpy+swigification of C code -- it's really handy. Knowing that swig wraps C code, I wasn't too surprised that there was the issue with complex data types (as described at http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#other-com...), but still it was pretty disappointing because most of my data is complex, and I'm invoking methods written to use C++'s std::complex class. After quite a bit of puzzling and not much help from previous mailing list posts, I created this very brief but very useful file, which I call numpy_std_complex.i -- /* -*- C -*- (not really, but good for syntax highlighting) */ #ifdef SWIGPYTHON %include "numpy.i" %include <std_complex.i> %numpy_typemaps(std::complex<float>, NPY_CFLOAT , int) %numpy_typemaps(std::complex<double>, NPY_CDOUBLE, int) #endif /* SWIGPYTHON */ I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land. Or if anyone wants to improve upon this usage I would be very happy to hear about what I'm missing. I'm sure there's a documented way to submit this file to the git repo, but let me simultaneously ask whether list subscribers think this is worthwhile and ask someone to add+push it for me … Thanks, Glen Mabey
Glen Mabey <gmabey@swri.org> wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land.
I don't think you do. But perhaps you overestimate the number of NumPy users who use Swig? Cython seems to be the preferred wrapping tool today, and it understands complex numbers: cdef double complex J = 0.0 + 1j If you tell Cython to emit C++, this will result in code that uses std::complex<double>. Sturla
On Oct 27, 2014, at 10:45 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Glen Mabey <gmabey@swri.org> wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land.
I don't think you do. But perhaps you overestimate the number of NumPy users who use Swig?
Likely so.
Cython seems to be the preferred wrapping tool today, and it understands complex numbers:
cdef double complex J = 0.0 + 1j
If you tell Cython to emit C++, this will result in code that uses std::complex<double>.
I chose swig after reviewing the options listed here, and I didn't see cython on the list: http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html I guess that's because cython is different language, right? So, if I want to interactively call C++ functions from say ipython, then is cython really an option? Thanks for the feedback -- Glen
Python is its own language, but it allows you to import C and C++ code, thus creating an interface to these languages. Just as with SWIG, you would import a module written in Cython that gives you access to underlying C/C++ code. Cython is very nice for a lot of applications, but it is not the best tool for every job of designing an interface. SWIG is still preferable if you have a large existing code base to wrap or if you want to support more target languages than just Python. I have a specific need for cross-language polymorphism, and SWIG is much better at that than Cython is. It all depends. Looks like somebody needs to update the c-info.python-as-glue.html page. -Bill On Oct 27, 2014, at 10:04 AM, Glen Mabey <gmabey@swri.org> wrote:
On Oct 27, 2014, at 10:45 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Glen Mabey <gmabey@swri.org> wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land.
I don't think you do. But perhaps you overestimate the number of NumPy users who use Swig?
Likely so.
Cython seems to be the preferred wrapping tool today, and it understands complex numbers:
cdef double complex J = 0.0 + 1j
If you tell Cython to emit C++, this will result in code that uses std::complex<double>.
I chose swig after reviewing the options listed here, and I didn't see cython on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
I guess that's because cython is different language, right? So, if I want to interactively call C++ functions from say ipython, then is cython really an option?
Thanks for the feedback -- Glen _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
Oops, I meant '"Cython" is its own language,' not "Python" (although Python qualifies, too, just not in context). Also, Pyrex, listed in the c-info.python-as-glue.html page, was the pre-cursor to Cython. -Bill On Oct 27, 2014, at 10:20 AM, Bill Spotz <wfspotz@sandia.gov> wrote:
Python is its own language, but it allows you to import C and C++ code, thus creating an interface to these languages. Just as with SWIG, you would import a module written in Cython that gives you access to underlying C/C++ code.
Cython is very nice for a lot of applications, but it is not the best tool for every job of designing an interface. SWIG is still preferable if you have a large existing code base to wrap or if you want to support more target languages than just Python. I have a specific need for cross-language polymorphism, and SWIG is much better at that than Cython is. It all depends.
Looks like somebody needs to update the c-info.python-as-glue.html page.
-Bill
On Oct 27, 2014, at 10:04 AM, Glen Mabey <gmabey@swri.org> wrote:
On Oct 27, 2014, at 10:45 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Glen Mabey <gmabey@swri.org> wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land.
I don't think you do. But perhaps you overestimate the number of NumPy users who use Swig?
Likely so.
Cython seems to be the preferred wrapping tool today, and it understands complex numbers:
cdef double complex J = 0.0 + 1j
If you tell Cython to emit C++, this will result in code that uses std::complex<double>.
I chose swig after reviewing the options listed here, and I didn't see cython on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
I guess that's because cython is different language, right? So, if I want to interactively call C++ functions from say ipython, then is cython really an option?
Thanks for the feedback -- Glen _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
Bill Spotz <wfspotz@sandia.gov> wrote:
Oops, I meant '"Cython" is its own language,' not "Python" (although Python qualifies, too, just not in context).
Also, Pyrex, listed in the c-info.python-as-glue.html page, was the pre-cursor to Cython.
But when it comes to interfacing NumPy, they are really not comparable. :-) Sturla
Glen Mabey <gmabey@swri.org> wrote:
I chose swig after reviewing the options listed here, and I didn't see cython on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
It's because that list is old and has not been updated. It has the predecessor to Cython, Pyrex, but they are very different now. Both SciPy and NumPy has Cython as a build dependency, and also projects like scikit-learn, scikit-image, statsmodels. If you find C++ projects which use Swig (wxPython, PyWin32) or SIP (PyQt) it is mainly because they are older than Cython. A more recent addition, PyZMQ, use Cython to wrap C++.
I guess that's because cython is different language, right? So, if I want to interactively call C++ functions from say ipython, then is cython really an option?
You can use Cython to call C++ functions in ipython and ipython notebook. cythonmagic takes care of that :-) Sturla
On Mon, Oct 27, 2014 at 4:27 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Glen Mabey <gmabey@swri.org> wrote:
I chose swig after reviewing the options listed here, and I didn't see cython on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
It's because that list is old and has not been updated. It has the predecessor to Cython, Pyrex, but they are very different now.
Both SciPy and NumPy has Cython as a build dependency, and also projects like scikit-learn, scikit-image, statsmodels.
If you find C++ projects which use Swig (wxPython, PyWin32) or SIP (PyQt) it is mainly because they are older than Cython. A more recent addition, PyZMQ, use Cython to wrap C++.
SWIG is a perfectly reasonable tool that is still used on new projects, and is a supported way of building extensions against numpy. Please stop haranguing the new guy for not knowing things that you know. This thread is about extending that support, a perfectly fine and decent thing to do. -- Robert Kern
Robert Kern <robert.kern@gmail.com> wrote:
Please stop haranguing the new guy for not knowing things that you know.
I am not doing any of that. You are the only one haranguing here. I usually ignore your frequent inpolite comments, but I will do an exception this time and ask you to shut up. Sturla
On Mon, Oct 27, 2014 at 11:36 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Robert Kern <robert.kern@gmail.com> wrote:
Please stop haranguing the new guy for not knowing things that you know.
I am not doing any of that. You are the only one haranguing here.
I understand that it's not your *intention*, so please take this as a well-meant caution from a outside observer that it *is* the effect of your words on other people, and if you intend something else, you may want to consider your words more carefully. The polite, welcoming response to someone coming along with a straightforward, obviously-correct contribution to our SWIG capabilities is "Thank you!", not "perhaps you overestimate the number of NumPy users who use Swig". You are entitled to your opinions on the relative merits of Cython and SWIG and to argue for them, but not every thread mentioning SWIG is an appropriate forum for hashing out that argument. -- Robert Kern
Robert Kern <robert.kern@gmail.com> wrote:
The polite, welcoming response to someone coming along with a straightforward, obviously-correct contribution to our SWIG capabilities is "Thank you!", not "perhaps you overestimate the number of NumPy users who use Swig".
That was a response to something else. As to why this issue with NumPy and Swig has not been solved before, the OP suggested he might have overestimated the number of NumPy users who also use std::complex in C++. Hence my answer he did not (it is arguably not that uncommon), but maybe they don't use Swig.
Glen, Supporting std::complex<> was just low enough priority for me that I decided to wait until someone expressed interest ... and now, many years later, someone finally has. I would be happy to include this into numpy.i, but I would like to see some tests in the numpy repository demonstrating that it works. These could be relatively short and simple, and since float and double are the only scalar data types that I could foresee supporting, there would not be a need for testing the large numbers of data types that the other tests cover. I would also want to protect the references to C++ objects with '#ifdef __cplusplus', but that is easy enough. -Bill On Oct 27, 2014, at 9:06 AM, Glen Mabey <gmabey@swri.org> wrote:
Hello,
I was very excited to learn about numpy.i for easy numpy+swigification of C code -- it's really handy.
Knowing that swig wraps C code, I wasn't too surprised that there was the issue with complex data types (as described at http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#other-com...), but still it was pretty disappointing because most of my data is complex, and I'm invoking methods written to use C++'s std::complex class.
After quite a bit of puzzling and not much help from previous mailing list posts, I created this very brief but very useful file, which I call numpy_std_complex.i --
/* -*- C -*- (not really, but good for syntax highlighting) */ #ifdef SWIGPYTHON
%include "numpy.i"
%include <std_complex.i>
%numpy_typemaps(std::complex<float>, NPY_CFLOAT , int) %numpy_typemaps(std::complex<double>, NPY_CDOUBLE, int)
#endif /* SWIGPYTHON */
I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land.
Or if anyone wants to improve upon this usage I would be very happy to hear about what I'm missing.
I'm sure there's a documented way to submit this file to the git repo, but let me simultaneously ask whether list subscribers think this is worthwhile and ask someone to add+push it for me …
Thanks, Glen Mabey _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
participants (4)
-
Bill Spotz -
Glen Mabey -
Robert Kern -
Sturla Molden