Re: [Numpy-discussion] diag, diagonal, ravel and all that

On Sat, Jan 3, 2015 at 4:54 PM, Sturla Molden wrote: > On 03/01/15 03:04, Charles R Harris wrote: > > > The diag, diagonal, and ravel functions have recently been changed to > > preserve subtypes. However, this causes lots of backward compatibility > > problems for matrix users, in particular, sc

Re: [Numpy-discussion] diag, diagonal, ravel and all that

On 03/01/15 03:04, Charles R Harris wrote: > The diag, diagonal, and ravel functions have recently been changed to > preserve subtypes. However, this causes lots of backward compatibility > problems for matrix users, in particular, scipy.sparse. One possibility > for fixing this is to special case

Re: [Numpy-discussion] The future of ndarray.diagonal()

On Sat, Jan 3, 2015 at 2:55 PM, Matthew Brett wrote: > Hi, > > On Thu, Jan 1, 2015 at 9:35 PM, Alexander Belopolsky > wrote: > > A discussion [1] is currently underway at GitHub which will benefit from > a > > larger forum. > > > > In version 1.9, the diagonal() method was changed to return a re

Re: [Numpy-discussion] The future of ndarray.diagonal()

Hi, On Thu, Jan 1, 2015 at 9:35 PM, Alexander Belopolsky wrote: > A discussion [1] is currently underway at GitHub which will benefit from a > larger forum. > > In version 1.9, the diagonal() method was changed to return a read-only > (non-contiguous) view into the original array instead of a pla

[Numpy-discussion] Regarding np.ma.masked_equal behavior

Hello friends, This is an issue related to the working of *masked_equal* method. I was thinking if anyone related to an old ticket #1851 , regarding the modification of *masked_equal *function effect on *fill_value *could clarify the situation, since rig

Re: [Numpy-discussion] The future of ndarray.diagonal()

Wasn't all of this discussed way back when the deprecation plan was made? This was known to happen and was entirely the intent, right? What new argument is there to deviate from the plan? As for that particular blog post, I remember reading it back when it was posted. I, again, sympathize with the

Re: [Numpy-discussion] The future of ndarray.diagonal()

On 1 Jan 2015 21:35, "Alexander Belopolsky" wrote: > > A discussion [1] is currently underway at GitHub which will benefit from a larger forum. > > In version 1.9, the diagonal() method was changed to return a read-only (non-contiguous) view into the original array instead of a plain copy. Also, i

Re: [Numpy-discussion] Optimizing multi-tensor contractions in numpy

Hello Nathaniel, > I'd also be interested in hearing more about the memory requirements of this > approach. How does the temporary memory required typically scale with the > size of the input arrays? Is there an upper bound on the temporary memory > required? > Currently the algorithm will not

Re: [Numpy-discussion] Correct C string handling in the NumPy C API?

Sturla Molden wrote: > Thanks. That explains it. 20 years after learning C I still discover new things... On the other hand, Fortran is Fortran, and seems to be free of these gotchas... Python is better as well. I hate to say it but C++ would also be less confusing here. I would just pass i

Re: [Numpy-discussion] diag, diagonal, ravel and all that

On Sat, Jan 3, 2015 at 10:54 AM, Alan G Isaac wrote: > > On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote: > >> Would this really be practicality beating purity? > >> It would be nice to have know the principle governing this. > >> For example, is there a way to convincingly group t

Re: [Numpy-discussion] Correct C string handling in the NumPy C API?

Nathaniel Smith wrote: > No, this code is safe (fortunately!). C string literals have "static > storage" (see paragraph 6.4.5.5 in C99), which means that their > lifetime is the same as the lifetime of a 'static char[]'. They aren't > stack allocated. Thanks. That explains it. Sturla

Re: [Numpy-discussion] Correct C string handling in the NumPy C API?

2015-01-03 18:15 GMT+00:00 Sturla Molden : > > Here is an example: > > NPY_NO_EXPORT NpyIter_IterNextFunc * > NpyIter_GetIterNext(NpyIter *iter, char **errmsg) > { > npy_uint32 itflags = NIT_ITFLAGS(iter); > int ndim = NIT_NDIM(iter); > int nop = NIT_NOP(iter); > > if (NIT_ITERS

[Numpy-discussion] Correct C string handling in the NumPy C API?

Here is an example: NPY_NO_EXPORT NpyIter_IterNextFunc * NpyIter_GetIterNext(NpyIter *iter, char **errmsg) { npy_uint32 itflags = NIT_ITFLAGS(iter); int ndim = NIT_NDIM(iter); int nop = NIT_NOP(iter); if (NIT_ITERSIZE(iter) < 0) { if (errmsg == NULL) { Py

Re: [Numpy-discussion] diag, diagonal, ravel and all that

> On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote: >> Would this really be practicality beating purity? >> It would be nice to have know the principle governing this. >> For example, is there a way to convincingly group these as >> array operations vs matrix operations? >> Pe

Re: [Numpy-discussion] Pass 2d ndarray into C **double using ctypes

Hi Sturla, First of all, my apologies to have spelled your name wrong for the past year - I just realized it! Thanks to Eric Firing who pointed this out to me. Thank you Sturla for bearing with me! And then - thank you for pointing out Numba! I tried to use it years ago, but ended up Cython event

Re: [Numpy-discussion] Optimizing multi-tensor contractions in numpy

On 3 Jan 2015 02:46, "Daniel Smith" wrote: > > Hello everyone, > > I have been working on a chunk of code that basically sets out to provide a single function that can take an arbitrary einsum expression and computes it in the most optimal way. While np.einsum can compute arbitrary expressions, th

Re: [Numpy-discussion] Add a function to broadcast arrays to a given shape to numpy's stride_tricks?

Here is an update on a new function for broadcasting arrays to a given shape (now named np.broadcast_to). I have a pull request up for review, which has received some feedback now: https://github.com/numpy/numpy/pull/5371 There is still at least one design decision to settle: should we expose "br

Re: [Numpy-discussion] diag, diagonal, ravel and all that

On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote: > Would this really be practicality beating purity? > It would be nice to have know the principle governing this. > For example, is there a way to convincingly group these as > array operations vs matrix operations? > > Personally I am puzzled b

Re: [Numpy-discussion] diag, diagonal, ravel and all that

Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`