Re: [Numpy-discussion] Which NumPy/Numpy/numpy spelling?

[Sebastian Berg]

On Di, 2016-08-30 at 12:17 -0700, Stefan van der Walt wrote:
> On Mon, Aug 29, 2016, at 04:43, m...@telenczuk.pl wrote:
> > 
> > The documentation is not consistent and it mixes both NumPy and
> > Numpy.
> > For example, the reference manual uses both spellings in the
> > introduction
> > paragraph (http://docs.scipy.org/doc/numpy/reference/):
> > 
> > "This reference manual details functions, modules, and objects
> > included in Numpy, describing what they are and what they do.
> > For
> > learning how to use NumPy, see also NumPy User Guide."
> That's technically a bug: the official spelling is NumPy.  But, no
> one
> really cares :)
> 

I like the fact that this is all posted in: [Numpy-discussion] ;).

- Sebastian

> Stéfan
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Michael Bieri]

Hi all

There are several ways on how to use C/C++ code from Python with NumPy, as
given in http://docs.scipy.org/doc/numpy/user/c-info.html . Furthermore,
there's at least pybind11.

I'm not quite sure which approach is state-of-the-art as of 2016. How would
you do it if you had to make a C/C++ library available in Python right now?

In my case, I have a C library with some scientific functions on matrices
and vectors. You will typically call a few functions to configure the
computation, then hand over some pointers to existing buffers containing
vector data, then start the computation, and finally read back the data.
The library also can use MPI to parallelize.

Best regards,
Michael
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Include last element when subindexing numpy arrays?

[Matti Viljamaa]

Is there a clean way to include the last element when subindexing numpy arrays?
Since the default behaviour of numpy arrays is to omit the “stop index”.

So for,

>>> A
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
>>> A[0:5]
array([0, 1, 2, 3, 4])

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Why np.fft.rfftfreq only returns up to Nyqvist?

[Matti Viljamaa]

What’s the reasonability of np.fft.rfftfreq returning frequencies only up to 
Nyquist, rather than for the full sample rate?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Include last element when subindexing numpy arrays?

[Robert Kern]

On Wed, Aug 31, 2016 at 12:28 PM, Matti Viljamaa  wrote:
>
> Is there a clean way to include the last element when subindexing numpy
arrays?
> Since the default behaviour of numpy arrays is to omit the “stop index”.
>
> So for,
>
> >>> A
> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> >>> A[0:5]
> array([0, 1, 2, 3, 4])

A[5:]

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why np.fft.rfftfreq only returns up to Nyqvist?

[Robert Kern]

On Wed, Aug 31, 2016 at 1:14 PM, Matti Viljamaa  wrote:
>
> What’s the reasonability of np.fft.rfftfreq returning frequencies only up
to Nyquist, rather than for the full sample rate?

The answer to the question that you asked is that np.fft.rfft() only
computes values for frequencies only up to Nyquist, so np.fft.rfftfreq()
must give you the frequencies to match. I'm not sure if there is another
misunderstanding lurking that needs to be clarified.

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Robert Kern]

On Wed, Aug 31, 2016 at 12:28 PM, Michael Bieri  wrote:
>
> Hi all
>
> There are several ways on how to use C/C++ code from Python with NumPy,
as given in http://docs.scipy.org/doc/numpy/user/c-info.html . Furthermore,
there's at least pybind11.
>
> I'm not quite sure which approach is state-of-the-art as of 2016. How
would you do it if you had to make a C/C++ library available in Python
right now?
>
> In my case, I have a C library with some scientific functions on matrices
and vectors. You will typically call a few functions to configure the
computation, then hand over some pointers to existing buffers containing
vector data, then start the computation, and finally read back the data.
The library also can use MPI to parallelize.

I usually reach for Cython:

http://cython.org/
http://docs.cython.org/en/latest/src/userguide/memoryviews.html

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Include last element when subindexing numpy arrays?

[Matti Viljamaa]

> On 31 Aug 2016, at 15:22, Robert Kern  wrote:
> 
> On Wed, Aug 31, 2016 at 12:28 PM, Matti Viljamaa  > wrote:
> >
> > Is there a clean way to include the last element when subindexing numpy 
> > arrays?
> > Since the default behaviour of numpy arrays is to omit the “stop index”.
> >
> > So for,
> >
> > >>> A
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> > >>> A[0:5]
> > array([0, 1, 2, 3, 4])
> 
> A[5:]
> 
> --
> Robert Kern

No that returns the subarray starting from index 5 to the end.

What I want to be able to return

array([0, 1, 2, 3, 4, 5])

(i.e. last element 5 included)

but without the funky A[0:6] syntax, which looks like it should return

array([0, 1, 2, 3, 4, 5, 6])

but since bumpy arrays omit the last index, returns

array([0, 1, 2, 3, 4, 5])

which syntactically would be more reasonable to be A[0:5].

> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Include last element when subindexing numpy arrays?

[Robert Kern]

On Wed, Aug 31, 2016 at 1:34 PM, Matti Viljamaa  wrote:
>
> On 31 Aug 2016, at 15:22, Robert Kern  wrote:
>
> On Wed, Aug 31, 2016 at 12:28 PM, Matti Viljamaa 
wrote:
> >
> > Is there a clean way to include the last element when subindexing numpy
arrays?
> > Since the default behaviour of numpy arrays is to omit the “stop index”.
> >
> > So for,
> >
> > >>> A
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> > >>> A[0:5]
> > array([0, 1, 2, 3, 4])
>
> A[5:]
>
> --
> Robert Kern
>
> No that returns the subarray starting from index 5 to the end.
>
> What I want to be able to return
>
> array([0, 1, 2, 3, 4, 5])
>
> (i.e. last element 5 included)
>
> but without the funky A[0:6] syntax, which looks like it should return
>
> array([0, 1, 2, 3, 4, 5, 6])
>
> but since bumpy arrays omit the last index, returns
>
> array([0, 1, 2, 3, 4, 5])
>
> which syntactically would be more reasonable to be A[0:5].

Ah, I see what you are asking now.

The answer is "no"; this is just the way that slicing works in Python in
general. numpy merely follows suit. It is something that you will get used
to with practice. My sense of "funkiness" and "reasonableness" is the
opposite of yours, for instance.

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Neal Becker]

Michael Bieri wrote:

> Hi all
> 
> There are several ways on how to use C/C++ code from Python with NumPy, as
> given in http://docs.scipy.org/doc/numpy/user/c-info.html . Furthermore,
> there's at least pybind11.
> 
> I'm not quite sure which approach is state-of-the-art as of 2016. How
> would you do it if you had to make a C/C++ library available in Python
> right now?
> 
> In my case, I have a C library with some scientific functions on matrices
> and vectors. You will typically call a few functions to configure the
> computation, then hand over some pointers to existing buffers containing
> vector data, then start the computation, and finally read back the data.
> The library also can use MPI to parallelize.
> 
> Best regards,
> Michael

I prefer ndarray:
https://github.com/ndarray/ndarray

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Reading in a mesh file

[Florian Lindner]

Hello,

I have mesh (more exactly: just a bunch of nodes) description with values 
associated to the nodes in a file, e.g. for a
3x3 mesh:

0   0   10
0   0.3 11
0   0.6 12
0.3 0   20
0.3 0.3 21
0.3 0.6 22
0.6 0   30
0.6 0.3 31
0.6 0.6 32

What is best way to read it in and get data structures like the ones I get from 
np.meshgrid?

Of course, I know about np.loadtxt, but I'm having trouble getting the 
resulting arrays (x, y, values) in the right form
and to retain association to the values.

Thanks,
Florian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Reading in a mesh file

[Robert Kern]

On Wed, Aug 31, 2016 at 4:00 PM, Florian Lindner 
wrote:
>
> Hello,
>
> I have mesh (more exactly: just a bunch of nodes) description with values
associated to the nodes in a file, e.g. for a
> 3x3 mesh:
>
> 0   0   10
> 0   0.3 11
> 0   0.6 12
> 0.3 0   20
> 0.3 0.3 21
> 0.3 0.6 22
> 0.6 0   30
> 0.6 0.3 31
> 0.6 0.6 32
>
> What is best way to read it in and get data structures like the ones I
get from np.meshgrid?
>
> Of course, I know about np.loadtxt, but I'm having trouble getting the
resulting arrays (x, y, values) in the right form
> and to retain association to the values.

For this particular case (known shape and ordering), this is what I would
do. Maybe throw in a .T or three depending on exactly how you want them to
be laid out.

[~/scratch]
|1> !cat mesh.txt

0   0   10
0   0.3 11
0   0.6 12
0.3 0   20
0.3 0.3 21
0.3 0.6 22
0.6 0   30
0.6 0.3 31
0.6 0.6 32

[~/scratch]
|2> nodes = np.loadtxt('mesh.txt')

[~/scratch]
|3> nodes
array([[  0. ,   0. ,  10. ],
   [  0. ,   0.3,  11. ],
   [  0. ,   0.6,  12. ],
   [  0.3,   0. ,  20. ],
   [  0.3,   0.3,  21. ],
   [  0.3,   0.6,  22. ],
   [  0.6,   0. ,  30. ],
   [  0.6,   0.3,  31. ],
   [  0.6,   0.6,  32. ]])

[~/scratch]
|4> reshaped = nodes.reshape((3, 3, -1))

[~/scratch]
|5> reshaped
array([[[  0. ,   0. ,  10. ],
[  0. ,   0.3,  11. ],
[  0. ,   0.6,  12. ]],

   [[  0.3,   0. ,  20. ],
[  0.3,   0.3,  21. ],
[  0.3,   0.6,  22. ]],

   [[  0.6,   0. ,  30. ],
[  0.6,   0.3,  31. ],
[  0.6,   0.6,  32. ]]])

[~/scratch]
|7> x = reshaped[..., 0]

[~/scratch]
|8> y = reshaped[..., 1]

[~/scratch]
|9> values = reshaped[..., 2]

[~/scratch]
|10> x
array([[ 0. ,  0. ,  0. ],
   [ 0.3,  0.3,  0.3],
   [ 0.6,  0.6,  0.6]])

[~/scratch]
|11> y
array([[ 0. ,  0.3,  0.6],
   [ 0. ,  0.3,  0.6],
   [ 0. ,  0.3,  0.6]])

[~/scratch]
|12> values
array([[ 10.,  11.,  12.],
   [ 20.,  21.,  22.],
   [ 30.,  31.,  32.]])

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Sylvain Corlay]

+1 on pybind11.

Sylvain

On Wed, Aug 31, 2016 at 1:28 PM, Michael Bieri  wrote:

> Hi all
>
> There are several ways on how to use C/C++ code from Python with NumPy, as
> given in http://docs.scipy.org/doc/numpy/user/c-info.html . Furthermore,
> there's at least pybind11.
>
> I'm not quite sure which approach is state-of-the-art as of 2016. How
> would you do it if you had to make a C/C++ library available in Python
> right now?
>
> In my case, I have a C library with some scientific functions on matrices
> and vectors. You will typically call a few functions to configure the
> computation, then hand over some pointers to existing buffers containing
> vector data, then start the computation, and finally read back the data.
> The library also can use MPI to parallelize.
>
> Best regards,
> Michael
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[David Morris]

On Wed, Aug 31, 2016 at 2:28 PM, Michael Bieri  wrote:

> Hi all
>
> There are several ways on how to use C/C++ code from Python with NumPy, as
> given in http://docs.scipy.org/doc/numpy/user/c-info.html . Furthermore,
> there's at least pybind11.
>
> I'm not quite sure which approach is state-of-the-art as of 2016. How
> would you do it if you had to make a C/C++ library available in Python
> right now?
>
> In my case, I have a C library with some scientific functions on matrices
> and vectors. You will typically call a few functions to configure the
> computation, then hand over some pointers to existing buffers containing
> vector data, then start the computation, and finally read back the data.
> The library also can use MPI to parallelize.
>

I have been delighted with Cython for this purpose.  Great integration with
NumPy (you can access numpy arrays directly as C arrays), very python like
syntax and amazing performance.

Good luck,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Jason Newton]

I just wanted to follow up on the C++ side of OP email - Cython has quite a
few difficulties working with C++ code at the moment.  It's really more of
a C solution most of the time and you must split things up into a mostly C
call interface (that is the C code Cython can call) and limit
exposure/complications with templates and  complex C++11+ constructs.  This
may change in the longer term but in the near, that is the state.

I used to use Boost.Python but I'm getting my feet wet with Pybind (which
is basically the same api but works more as you expect it to with it's
signature/type plumbing  (including std::shared_ptr islanding), with some
other C++11 based improvements, and is header only + submodule friendly!).
I also remembered ndarray thanks to Neal's post but I haven't figured out
how to leverage it better than pybind, at the moment.  I'd be interested to
see ndarray gain support for pybind interoperability...

-Jason

On Wed, Aug 31, 2016 at 1:08 PM, David Morris  wrote:

> On Wed, Aug 31, 2016 at 2:28 PM, Michael Bieri  wrote:
>
>> Hi all
>>
>> There are several ways on how to use C/C++ code from Python with NumPy,
>> as given in http://docs.scipy.org/doc/numpy/user/c-info.html .
>> Furthermore, there's at least pybind11.
>>
>> I'm not quite sure which approach is state-of-the-art as of 2016. How
>> would you do it if you had to make a C/C++ library available in Python
>> right now?
>>
>> In my case, I have a C library with some scientific functions on matrices
>> and vectors. You will typically call a few functions to configure the
>> computation, then hand over some pointers to existing buffers containing
>> vector data, then start the computation, and finally read back the data.
>> The library also can use MPI to parallelize.
>>
>
> I have been delighted with Cython for this purpose.  Great integration
> with NumPy (you can access numpy arrays directly as C arrays), very python
> like syntax and amazing performance.
>
> Good luck,
>
> David
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Ian Henriksen]

We use Cython very heavily in DyND's Python bindings. It has worked well
for us
even when working with some very modern C++. That said, a lot depends on
exactly which C++ features you want to expose as a part of the interface.
Interfaces that require things like non-type template parameters or variadic
templates will often require a some extra C++ code to work them in to
something
that Cython can understand. In my experience, those particular limitations
haven't
been that hard to work with.
Best,
Ian Henriksen

On Wed, Aug 31, 2016 at 12:20 PM Jason Newton  wrote:

> I just wanted to follow up on the C++ side of OP email - Cython has quite
> a few difficulties working with C++ code at the moment.  It's really more
> of a C solution most of the time and you must split things up into a mostly
> C call interface (that is the C code Cython can call) and limit
> exposure/complications with templates and  complex C++11+ constructs.  This
> may change in the longer term but in the near, that is the state.
>
> I used to use Boost.Python but I'm getting my feet wet with Pybind (which
> is basically the same api but works more as you expect it to with it's
> signature/type plumbing  (including std::shared_ptr islanding), with some
> other C++11 based improvements, and is header only + submodule friendly!).
> I also remembered ndarray thanks to Neal's post but I haven't figured out
> how to leverage it better than pybind, at the moment.  I'd be interested to
> see ndarray gain support for pybind interoperability...
>
> -Jason
>
> On Wed, Aug 31, 2016 at 1:08 PM, David Morris  wrote:
>
>> On Wed, Aug 31, 2016 at 2:28 PM, Michael Bieri  wrote:
>>
>>> Hi all
>>>
>>> There are several ways on how to use C/C++ code from Python with NumPy,
>>> as given in http://docs.scipy.org/doc/numpy/user/c-info.html .
>>> Furthermore, there's at least pybind11.
>>>
>>> I'm not quite sure which approach is state-of-the-art as of 2016. How
>>> would you do it if you had to make a C/C++ library available in Python
>>> right now?
>>>
>>> In my case, I have a C library with some scientific functions on
>>> matrices and vectors. You will typically call a few functions to configure
>>> the computation, then hand over some pointers to existing buffers
>>> containing vector data, then start the computation, and finally read back
>>> the data. The library also can use MPI to parallelize.
>>>
>>
>> I have been delighted with Cython for this purpose.  Great integration
>> with NumPy (you can access numpy arrays directly as C arrays), very python
>> like syntax and amazing performance.
>>
>> Good luck,
>>
>> David
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Jason Newton]

Hey Ian - I hope I gave Cython a fair comment, but I have to add the
disclaimer that your capability to understand/implement those
solutions/workarounds in that project is greatly enhanced from your knowing
the innards of Cython from being core developer on the Cython project. This
doesn't detract from DyDN's accomplishments (if nothing it means Cython
users should look there for how to use C++ with Cython and the workarounds
used + shortcomings) but I would not expect not everyone would want to jump
through those hoops to get things working without a firm understanding of
Cython's edges, and all this potential for special/hack adaption code is
still something to keep in mind when comparing to something more straight
forward and easier to understand coming from a more pure C/C++ side, where
things are a bit more dangerous and fairly more verbose but make play with
the language and environment first-class (like Boost.Python/pybind).  Since
this thread is a survey over state and options it's my intent just to make
sure readers have something bare in mind for current pros/cons of the
approaches.

-Jason

On Wed, Aug 31, 2016 at 2:17 PM, Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:

> We use Cython very heavily in DyND's Python bindings. It has worked well
> for us
> even when working with some very modern C++. That said, a lot depends on
> exactly which C++ features you want to expose as a part of the interface.
> Interfaces that require things like non-type template parameters or
> variadic
> templates will often require a some extra C++ code to work them in to
> something
> that Cython can understand. In my experience, those particular limitations
> haven't
> been that hard to work with.
> Best,
> Ian Henriksen
>
>
> On Wed, Aug 31, 2016 at 12:20 PM Jason Newton  wrote:
>
>> I just wanted to follow up on the C++ side of OP email - Cython has quite
>> a few difficulties working with C++ code at the moment.  It's really more
>> of a C solution most of the time and you must split things up into a mostly
>> C call interface (that is the C code Cython can call) and limit
>> exposure/complications with templates and  complex C++11+ constructs.  This
>> may change in the longer term but in the near, that is the state.
>>
>> I used to use Boost.Python but I'm getting my feet wet with Pybind (which
>> is basically the same api but works more as you expect it to with it's
>> signature/type plumbing  (including std::shared_ptr islanding), with some
>> other C++11 based improvements, and is header only + submodule friendly!).
>> I also remembered ndarray thanks to Neal's post but I haven't figured out
>> how to leverage it better than pybind, at the moment.  I'd be interested to
>> see ndarray gain support for pybind interoperability...
>>
>> -Jason
>>
>> On Wed, Aug 31, 2016 at 1:08 PM, David Morris 
>> wrote:
>>
>>> On Wed, Aug 31, 2016 at 2:28 PM, Michael Bieri 
>>> wrote:
>>>
 Hi all

 There are several ways on how to use C/C++ code from Python with NumPy,
 as given in http://docs.scipy.org/doc/numpy/user/c-info.html .
 Furthermore, there's at least pybind11.

 I'm not quite sure which approach is state-of-the-art as of 2016. How
 would you do it if you had to make a C/C++ library available in Python
 right now?

 In my case, I have a C library with some scientific functions on
 matrices and vectors. You will typically call a few functions to configure
 the computation, then hand over some pointers to existing buffers
 containing vector data, then start the computation, and finally read back
 the data. The library also can use MPI to parallelize.

>>>
>>> I have been delighted with Cython for this purpose.  Great integration
>>> with NumPy (you can access numpy arrays directly as C arrays), very python
>>> like syntax and amazing performance.
>>>
>>> Good luck,
>>>
>>> David
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Stefan van der Walt]

On Wed, Aug 31, 2016, at 13:57, Jason Newton wrote:
> Hey Ian - I hope I gave Cython a fair comment, but I have to add the
> disclaimer that your capability to understand/implement those
> solutions/workarounds in that project is greatly enhanced from your
> knowing the innards of Cython from being core developer on the Cython
> project. This doesn't detract from DyDN's accomplishments (if nothing
> it means Cython users should look there for how to use C++ with Cython
> and the workarounds used + shortcomings) but I would not expect not
> everyone would want to jump through those hoops to get things working
> without a firm understanding of Cython's edges, and all this potential
> for special/hack adaption code is still something to keep in mind when
> comparing to something more straight forward and easier to understand
> coming from a more pure C/C++ side, where things are a bit more
> dangerous and fairly more verbose but make play with the language and
> environment first-class (like Boost.Python/pybind).  Since this thread
> is a survey over state and options it's my intent just to make sure
> readers have something bare in mind for current pros/cons of the
> approaches.

There are many teaching resources available for Cython, after which
exposure to sharp edges may be greatly reduced.  See, e.g.,

https://github.com/stefanv/teaching/blob/master/2014_assp_split_cython/slides/split2014_cython.pdf

and accompanying problems and exercises at

https://github.com/stefanv/teaching/tree/master/2014_assp_split_cython

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

[Ian Henriksen]

On Wed, Aug 31, 2016 at 3:57 PM Jason Newton  wrote:

> Hey Ian - I hope I gave Cython a fair comment, but I have to add the
> disclaimer that your capability to understand/implement those
> solutions/workarounds in that project is greatly enhanced from your knowing
> the innards of Cython from being core developer on the Cython project. This
> doesn't detract from DyDN's accomplishments (if nothing it means Cython
> users should look there for how to use C++ with Cython and the workarounds
> used + shortcomings) but I would not expect not everyone would want to jump
> through those hoops to get things working without a firm understanding of
> Cython's edges, and all this potential for special/hack adaption code is
> still something to keep in mind when comparing to something more straight
> forward and easier to understand coming from a more pure C/C++ side, where
> things are a bit more dangerous and fairly more verbose but make play with
> the language and environment first-class (like Boost.Python/pybind).  Since
> this thread is a survey over state and options it's my intent just to make
> sure readers have something bare in mind for current pros/cons of the
> approaches.
>
> -Jason
>

No offense taken at all. I'm actually not a Cython developer, just a
frequent
contributor. That said, knowing the compiler internals certainly helps when
finding
workarounds and building intermediate interfaces. My main point was just
that, in
my experience, Cython has worked well for many things beyond plain C
interfaces
and that workarounds (hackery entirely aside) for any missing features are
usually
manageable. Given that my perspective is a bit different in that regard, it
seemed
worth chiming in on the discussion. I suppose the moral of the story is
that there's
still not a clear cut "best" way of building wrappers and that your mileage
may vary
depending on what features you need.
Thanks,
Ian Henriksen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion