[Numpy-discussion] Linear algebra functions on empty arrays

convention for this, or what convention we should implement. Regards, Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy

Re: [Numpy-discussion] Tracking and inspecting numpy objects

y is a single python object without any referenced objects (except possibly its `arr.base`). Second of all -- and this is an issue -- numpy doesn't actually implement the traverse slot, so it won't even work for object arrays (numpy object arrays do not support circular garbage collection at

Re: [Numpy-discussion] Tracking and inspecting numpy objects

On Mo, 2014-09-15 at 12:05 +0200, Eelco Hoogendoorn wrote: > > > > On Mon, Sep 15, 2014 at 11:55 AM, Sebastian Berg > wrote: > On Mo, 2014-09-15 at 10:16 +0200, Mads Ipsen wrote: > > Hi, > > > > I am trying to inspect

Re: [Numpy-discussion] Linear algebra functions on empty arrays

On Mo, 2014-09-15 at 07:07 -0400, josef.p...@gmail.com wrote: > On Mon, Sep 15, 2014 at 5:48 AM, Sebastian Berg > wrote: > > Hey all, > > > > for https://github.com/numpy/numpy/pull/3861/files I would like to allow > > 0-sized dimensions for generalized ufuncs, mean

Re: [Numpy-discussion] Is this a bug?

.dot, anyway; apparently it does work that > way for the brand-new gufunc np.linalg.matrix_multiply, but this must > be an accident). Agreed, the only argument to not change it right away would be being afraid of breaking user code abusing the kind of thing Josef mentioned. - Sebastian >

Re: [Numpy-discussion] Is this a bug?

bably, including no contiguity being enforced (or actually, maybe we can define 'K' to mean that in this context). To be honest, if 'K' means that, it seems like a decent default. - Sebastian > > > > > Chuck > > ___

Re: [Numpy-discussion] float('inf') // 1 = ?

thinking that floordivide is basically a divide+floor operation, but arguing for NaN seems half arsed to me on first sight. Either it is `inf` and the equivalence Benjamin Root noted holds or you make it an error. NaN is not reasonable for an error return *especially* not for the standard lib (it

Re: [Numpy-discussion] float('inf') // 1 = ?

On Do, 2014-09-18 at 19:13 +0200, Sebastian Berg wrote: > On Thu, 2014-09-18 at 18:55 +0200, Petr Viktorin wrote: > > Sorry for the lack of subject before. > > > > On Thu, Sep 18, 2014 at 6:48 PM, Benjamin Root wrote: > > > My vote is that NumPy is cor

Re: [Numpy-discussion] Proposal: add ndarray.keys() to return dtype.names

So, for non-structured arrays, the consens is an Exception. The question is, which one. AttributeError would be fully backwards compatible. Existing code checks for the method and if it exists, the object has fields. ValueError would make more sense, as the value - the array - is in wrong format/st

Re: [Numpy-discussion] use ufunc for arbitrary positional arguments?

gt; Of course np.all is pretty much identical to np.logical_and.reduce(), and that is defined for all ufuncs. Of course your list of arrays will be converted to one large array first, so the python reduce may actually be faster in many cases. - Sebastian > > Thanks! > > Ben Root &

Re: [Numpy-discussion] Best way to expose std::vector to be used with numpy

iew object in python 2, which maybe could be used to the same effect? - Sebastian > > What is the best thing to do to expose the data buffer to python 2, > without introducing a dependency on numpy in the application? > > Bonus points if the proposed solution comes with a pointer on

Re: [Numpy-discussion] Why ndarray provides four ways to flatten?

avel can even get further if you use order='K'. - Sebastian > > >>> x = np.arange(10) > >>> y = x[::2] > >>> y.ravel().flags['OWNDATA'] > True > > > Interestingly, in the same case reshape(-1) returns a view: > >

Re: [Numpy-discussion] Why ndarray provides four ways to flatten?

u keep in mind how buffers are copied around inside it, using half its features is dangerous. - Sebastian > Alan > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.

Re: [Numpy-discussion] help using np.einsum for stacked matrix multiplication

he future, the np.dot predecessor (whatever it is) or the @ operator should be better at it though. - Sebastian > Can anyone help, please? > > > cheers, > Andrew. > > > -- > _ > Dr. Andrew Nelson > > > ___

Re: [Numpy-discussion] help using np.einsum for stacked matrix multiplication

On Mi, 2014-10-29 at 13:05 +0100, Sebastian Berg wrote: > On Mi, 2014-10-29 at 20:39 +1100, Andrew Nelson wrote: > > Dear list, > > I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to > > perform matrix multiplication of the 'NY' 2x2 matrices, re

[Numpy-discussion] #2522 numpy.diff fails on unsigned integers

Hello, I want to bring up Issue #2522 'numpy.diff fails on unsigned integers (Trac #1929)' [1], as it was resonsible for an error in one of our programs. Short explanation of the bug: np.diff performs a subtraction on the input array. If this is of type uint and the data contains falling data,

Re: [Numpy-discussion] truthiness of object arrays

rue). > Antony > First sight, sounds like a bug. It should be passing out the error raised by the array inside. Can you open an issue? - Sebastian > 2014-11-12 20:15 GMT-08:00 Michael Sarahan : > Hi Antony, > > In general, you can't use numpy array

Re: [Numpy-discussion] truthiness of object arrays

han one element is > ambiguous. Use a.any() or a.all() > Note that the error is set, but appears to be not indicated within the C-api. This can cause errors to be missed or appear later then they should... Might be just that you are seeing, though I could not find a reason for it in the numpy c

Re: [Numpy-discussion] Setting up a "newcomers" label on the issue tracker ?

On Mi, 2014-11-26 at 08:44 +, David Cournapeau wrote: > Hi, > > > Would anybody mind if I create a label "newcomers" on GH, and start > labelling simple issues ? We actually have an "easy fix" label, which I think had this in mind. However, I admit that I think some of these issues may not b

Re: [Numpy-discussion] Should ndarray be a context manager?

insically dangerous this is, and how easily it can be > > implemented using numpy's existing public API, I think maybe we should > > leave this for third-party daredevils instead of implementing it in numpy > > proper. > > It seems so :-) Completly agree, we may tell

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

ng like: np.common_shape(*arrays) np.broadcast_to(array, shape) # (though I would like many arrays too) and then broadcast_ar rays could be implemented in terms of these two. Just some thoughts, Sebastian > Pierre > ___ > NumPy-Discussion

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

On Do, 2014-12-11 at 16:20 +, Robert Kern wrote: > On Thu, Dec 11, 2014 at 4:17 PM, Sebastian Berg > wrote: > > > > On Do, 2014-12-11 at 16:56 +0100, Pierre Haessig wrote: > > > Le 11/12/2014 16:52, Robert Kern a écrit : > > > > > > > &g

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

On Fr, 2014-12-12 at 05:48 -0800, Jaime Fernández del Río wrote: > On Thu, Dec 11, 2014 at 10:53 AM, Stephan Hoyer > wrote: > On Thu, Dec 11, 2014 at 8:17 AM, Sebastian Berg > wrote: > One option > would also be to h

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

On Fr, 2014-12-12 at 06:25 -0800, Jaime Fernández del Río wrote: > On Fri, Dec 12, 2014 at 5:57 AM, Sebastian Berg > wrote: > On Fr, 2014-12-12 at 05:48 -0800, Jaime Fernández del Río > wrote: > > On Thu, Dec 11, 2014 at 10:53 AM, Stephan Hoyer >

Re: [Numpy-discussion] edge-cases of ellipsis indexing

2. Slicing, etc. which returns a view. This also occurs as soon there is an ellipsis in there (even if it replaces 0 `:`). You should see it as a feature to get a view if the result might be a scalar otherwise ;)! 3. Advanced indexing which cannot be view based and returns a copy. - Seb

Re: [Numpy-discussion] Equality of dtypes does not imply equality of type kinds

tegers on 32-bit platforms and 64-bit integers on 64-bit platforms, but > neither of these constructors is called "long". Instead, they are called > numpy.int_ and numpy.intp. > There is np.long. int_ is python int which is long. intp is actually ssizet. - Sebastian

Re: [Numpy-discussion] Float view of complex array

> >>> np.__version__ > '1.9.0' > > and I don't understand why. When looking at the memory layout, I think > it should be possible. > Yes, it should be possible, but it is not :). You could hack it by using `np.ndarray` (or stride trick

Re: [Numpy-discussion] Float view of complex array

On Mo, 2015-01-26 at 02:02 -0800, Jaime Fernández del Río wrote: > On Mon, Jan 26, 2015 at 1:41 AM, Sebastian Berg > wrote: > On Mo, 2015-01-26 at 09:24 +0100, Jens Jørgen Mortensen wrote: > > Hi! > > > > I have a view of a 2-d complex

Re: [Numpy-discussion] Views of a different dtype

wap order pretty fast when operating on them, which can create impossibly to find bugs, because even a poweruser is likely to forget about such things. Of course you could argue that view is a poweruser feature and a user using it should keep these things in mind Though if yo

Re: [Numpy-discussion] Numpy 'None' comparison FutureWarning

nce the result won't actually change unless your array really *does* include None, and then I hope you want that change ;). - Sebastian > Ben Root > > > On Sun, Sep 21, 2014 at 10:53 PM, Nathaniel Smith > wrote: > On 22 Sep 2014 03:02, "Demitri Muna" >

Re: [Numpy-discussion] Views of a different dtype

On Mo, 2015-02-02 at 06:25 -0800, Jaime Fernández del Río wrote: > On Sat, Jan 31, 2015 at 1:17 AM, Sebastian Berg > wrote: > On Fr, 2015-01-30 at 19:52 -0800, Jaime Fernández del Río > wrote: > > On Thu, Jan 29, 2015 at 8:57 A

Re: [Numpy-discussion] Views of a different dtype

uddenly the fortran order array might be expanded along a 1-sized axis, because it is also C order. So I wonder if we can fix these regressions and at the same time maybe provide a more intuitive approach then using the memory order blin

Re: [Numpy-discussion] advanced indexing question

his for us): x[:,d,:,d] = x[:,d,:,d] + 1 so there is an item assignment going on (__setitem__ not __getitem__) - Sebastian > Thanks, > David > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailm

Re: [Numpy-discussion] Matrix Class

On Di, 2015-02-10 at 15:07 -0700, cjw wrote: > It seems to be agreed that there are weaknesses in the existing Numpy Matrix > Class. > > Some problems are illustrated below. > Not to delve deeply into a discussion, but unfortunately, there seem far more fundamental problems because of the always

Re: [Numpy-discussion] Matrix Class

On Mi, 2015-02-11 at 11:38 -0500, cjw wrote: > > On 11-Feb-15 10:47 AM, Sebastian Berg wrote: > > > On Di, 2015-02-10 at 15:07 -0700, cjw wrote: > > > It seems to be agreed that there are weaknesses in the existing Numpy > > > Matrix > > > Class. > &

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

upport for nditer? NDiter is pretty powerful, but we often have things like the contiguous special case, buffering, etc. that is always identical code but without having something ready in cython nobody will ever use nditer from cython, even though for some things it migh

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

deprecating it and not allowing pickles as default, but I am not sure that is not going too far. However, I think we should be able to safely share data using npy. - Sebastian > -- > Robert Kern > ___ > NumPy-Discussion mailing list >

Re: [Numpy-discussion] numpy array casting ruled not safe

tly > valid uint64 array because we want to protect them from themselves. > Sebastian has probably given this more thought than anyone else, it > would be interesting to hear his thoughts on this. > Not really, there was no change in behaviour for arrays here. Apparently though (which I

Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal

On Di, 2015-03-10 at 11:22 -0700, Nathaniel Smith wrote: > On Mar 10, 2015 11:15 AM, "Paul Hobson" wrote: > > > > > > On Mon, Mar 9, 2015 at 4:33 PM, Charles R Harris > wrote: > >> > >> > >> > >> On Mon, Mar 9, 2015 at 2:34 PM, Paul Hobson > wrote: > >>> > >>> I feel your pain. Making it worse,

Re: [Numpy-discussion] argument handling by uniform

> I think all of random broadcasts all of these arguments. So if you give two bounds, then you get one of each, could even do a grid of parameter combinations. - Sebastian > Thanks, > Alan Isaac > > ___ > NumPy-Discussion m

Re: [Numpy-discussion] Fastest way to compute summary statistics for a specific axis

n do a.mean((0, 1)). Though it isn't actually faster in this example, probably because it has to use buffered iterators and things, but I would guess the performance should be much more stable depending on memory order, etc. then any other method. - Sebastian > > ...but this won't

Re: [Numpy-discussion] How to Force Storage Order

lementation detail changes you are not relying on "this function will give me back a fortran ordered array". Of course you can do tricks to make this extra function call a no-op, since it will do nothing if the array is already in the correct memory order. But the quick check

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Do, 2015-04-02 at 01:29 -0700, Stephan Hoyer wrote: > On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río > wrote: > Is there any other package implementing non-orthogonal > indexing aside from numpy? > > > I think we can safely say that NumPy's implementation of broadcast

Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING

; I still have some small doubts that leaving relaxed strides as default will work out for 1.10, plus we will have to make "debugging mode" switchable (default off), and abusing the flag with different values for it is probably simplest. So my guess is, we should wait at least on

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

d be done easily inside the preparation function. The second axis remapping is probably reasonably easy (if, like the first thing, tedious). - Sebastian PS: One side comment about the discussion. I don't think anyone suggests that we should not/do not even consider proposals as such, even if it

Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING

On So, 2015-04-05 at 07:08 -0600, Charles R Harris wrote: > > > On Sun, Apr 5, 2015 at 4:37 AM, Sebastian Berg > wrote: > On Fr, 2015-04-03 at 21:00 -0600, Charles R Harris wrote: > > Hi All, > > > > > > Just to

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On So, 2015-04-05 at 14:13 +0200, Sebastian Berg wrote: > On So, 2015-04-05 at 00:45 -0700, Jaime Fernández del Río wrote: > > On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río > > > > > > > A PR it is, #5749 to be precise. I think it has all the be

Re: [Numpy-discussion] Multidimensional Indexing

you would probably also expect. One warning: If you index with more then one array (scalars are also arrays in this sense -- so `[0, :, array]` is an example) in combination with slices, the result can be transposed in a confusing way (it is not that difficult, but usually unexpected). - Sebas

Re: [Numpy-discussion] Non-meta indexing improvements discussion

On Do, 2015-04-09 at 08:50 +0200, Sebastian Berg wrote: > Hi all, > > Let me take a shot at summing up some suggestions to make the indexing > less surprising, and maybe we can gather some more in a more > concentrated way now. > Did not want to comment on the first ma

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

indices are not consecutive and you cannot add the fancy dimensions to where they were. I think you mentioned an error in the docu, I thought I cleared some of them, but proabably that did not make it more understandable sometimes. The whole subspace way of is used, but there is a lot of improvement

[Numpy-discussion] SIAM meeting in Snowbird anyone?

Hey, since I am not in the US often and the SIAM conference is pretty large, I was wondering if some more of our community will be at the SIAM conference in Snowbird around May 17th-21st and would like to meet up then. - Sebastian signature.asc Description: This is a digitally signed message

[Numpy-discussion] Non-meta indexing improvements discussion

self for a while at least. - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

ght be a nice way to make it easier to find. - Sebastian On Di, 2015-04-14 at 22:18 -0400, Nathaniel Smith wrote: > I am, yes. > > On Apr 14, 2015 9:17 PM, "Neil Girdhar" wrote: > Ok, I didn't know that. Are you at pycon by any chance? > >

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

se error for np.outer on non 1D arrays > I think that was Neil's proposal a bit earlier, too. +1 for it in any case, since at least for the moment I doubt outer is used a lot for non 1-d arrays. Possible step 3) make it work on higher dims after a long period. -

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 10:47 -0400, josef.p...@gmail.com wrote: > On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg > wrote: > > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: > >> Hi, > >> > > > >> > >> So, how about a slight modific

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

>> > > >> > > >> > On Fri, Apr 17, 2015 at 10:47 AM, wrote: > >> >> > >> >> On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg > >> >> wrote: > >> >> > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wro

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 20:56 +0200, Sebastian Berg wrote: > On Fr, 2015-04-17 at 12:40 -0400, josef.p...@gmail.com wrote: > > On Fri, Apr 17, 2015 at 12:16 PM, Neil Girdhar > > wrote: > > > > > > > > > On Fri, Apr 17, 2015 at 12:09 PM, wrote: > >

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 15:18 -0400, josef.p...@gmail.com wrote: > On Fri, Apr 17, 2015 at 2:56 PM, Sebastian Berg > > Hehe, yeah, that difference. But if you really want that, you can > > usually do a1[0, 1, ...] if you don't mind the ugliness. > > I'm not sure wh

Re: [Numpy-discussion] performance of numpy.array()

There was a major improvement to np.array in some cases. You can probably work around this by using np.concatenate instead of np.array in your case (depends on the usecase, but I will guess you have code doing: np.array([arr1, arr2, arr3]) or similar. If your use case is different, you may be ou

Re: [Numpy-discussion] Should ndarray subclasses support the keepdims arg?

raised due to the invalid **kwargs trick when the subclass does not support it? First sight it seems like a far shot have a hard requirement. The transition period alone seems hard, unless we have add magic to test the subclass upon creation, and I am not sure that is easy to do (someth

Re: [Numpy-discussion] Chaining apply_over_axis for multiple axes.

ly check some examples for it from the numpy tests to see how it works probably. - Sebastian > > If I have an array with shape (2, 3, 4) this would allow me to iterate > over the 6 1D arrays that are 4 elements long. However, how do I then > construct the iterator for the preceding axes

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

hat it does...: This is not being deprecated in there for the moment, it is a different discussion. Though maybe we can improve the error message to mention that the array was originally boolean, has always been bugging me a bit (it used to mention for some cases it is not anymore). - Seba

Re: [Numpy-discussion] variable end border in arrays

se's ? (I work with images and > tensor's so if/else's have too many possible combinations) > Yes and no. You could do if/else and use a None. Or just use the positive index: x[border[0]:x.shape[0] - border[1]]. - Sebastian > Thanks, > Pablo > ___

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

iple booleans, I think is more part of the "outer" indexing discussion, which is interesting but not here :). - Sebastian > > The second case where the boolean mask has an extra dimension of > length one, or several boolean arrays might need more checking. > I'm prett

Re: [Numpy-discussion] Open CV 3.0 + NPY_RELAXED_STRIDES

ity if someone gets a new numpy on top of oldish other packages. So I am good with planning to go ahead for the moment. But if anyone complains, I would back down for 1.10 probably. - Sebastian > > Chuck > > > > ___ > Num

Re: [Numpy-discussion] Python 3 and isinstance(np.int64(42), int)

(deprecation pending) and 0D arrays (will continue) say they are integers when asked that way. - Sebastian On Mi, 2015-06-17 at 23:13 -0700, Nathaniel Smith wrote: > On Wed, Jun 17, 2015 at 10:53 PM, Jens Jørgen Mortensen > wrote: > > >>> type(n) > > > >

Re: [Numpy-discussion] Flag for np.tile to use as_strided to reduce memory

hat (or you want to take a shot ;)). - Sebastian > > It would be easier than having to use as_strided or broadcast_arrays > to repeat data without actually replicating it. > > > http://stackoverflow.com/questions/23695851/python-repeating-numpy-array-without-replicating-da

Re: [Numpy-discussion] I can't tell if Numpy is configured properly with show_config()

much faster, but there were for example quite a few speedups in the code converting to array, so I expect it is very likely that this is the reason. - Sebastian > ### > > fast one > ### > > In [1]: import time, numpy > > In [2]: n=1000 > > In [3]: A = numpy.rand

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

also just round silently already. - Sebastian > > for example > > > >>> 5.0 == 5 > True > > > >>> np.ones(10 / 2) > array([ 1., 1., 1., 1., 1.]) > >>> 10 / 2 == 5 > True > > > or the python 2 version > > > >>

Re: [Numpy-discussion] np.nonzero - order guarantees?

Yes, I think it is guaranteed C order in the results. On Mon Jul 27 14:05:01 2015 GMT+0200, Matthew Brett wrote: > Hi, > > `np.nonzero` for a 2D array `A` returns: > > row_inds, col_inds = np.nonzero(A) > > I notice that `row_inds` appears to be sorted by value, and `col_inds` > appears to be

Re: [Numpy-discussion] Shared memory check on in-place modification.

On Mon Jul 27 22:51:52 2015 GMT+0200, Sturla Molden wrote: > On 27/07/15 22:10, Anton Akhmerov wrote: > > Hi everyone, > > > > I have encountered an initially rather confusing problem in a piece of > > code that attempted to symmetrize a matrix: `h += h.T` > > The problem of course appears due to

Re: [Numpy-discussion] np.nonzero - order guarantees?

On Tue Jul 28 18:18:01 2015 GMT+0200, Matthew Brett wrote: > On Tue, Jul 28, 2015 at 4:45 PM, Sebastian Berg > wrote: > > Yes, I think it is guaranteed C order in the results. > > > > > > On Mon Jul 27 14:05:01 2015 GMT+0200, Matthew Brett wrote: > >> Hi, &

Re: [Numpy-discussion] Change default order to Fortran order

Well, numpy has a tendency to prefer C order. There is nothing you can do about that really. But you just cannot be sure what you get in some cases. Often you need something specific for interfaceing other code. But in that case quite often you also do not need to fear the copy. - Sebastian

Re: [Numpy-discussion] Change default order to Fortran order

x positions: > > In [7]: import numpy as np > In [8]: np.all(data == data) > Out[8]: memmap(True, dtype=bool) > > but I now have a C memory layout array. > > In [9]: data_copy.flags > Out[9]: > C_CONTIGUOUS : True > F_CONTIGUOUS : False > OWNDATA : True &

Re: [Numpy-discussion] Change default order to Fortran order

gt; which will reverse the previous reshape in the correct way. > > But in any case - this is not directly to do with the array memory > layout. You will get the same output from reshape whether the memory > layout of `data` was Fortran or C. > Just as a remark. Reshape

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

e below the table (maybe the table should also note these): Additionally to intc the platform dependent C integer types short, long, longlong and their unsigned versions are defined. - Sebastian > > Sturla > > > > ___ > NumP

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > On 03/08/15 20:51, Chris Barker wrote: > > > well, IIUC, np.int is the python integer type, which is > > a C long in all the implemtations of cPython that I know about -- but is > > that a guarantee?in the future as well? >

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Di, 2015-08-04 at 05:57 -0400, josef.p...@gmail.com wrote: > > > On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg > wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > >

Re: [Numpy-discussion] Shared memory check on in-place modification.

a bad idea anyway), you have to avoid it. Pauli is working currently on implementing the logic needed to find if such a copy is necessary [1] which is very cool indeed. So I think it is likely we will such copy logic in NumPy 1.11. - Sebastian [1] See https://github.com/numpy/numpy/pull/6166 it

Re: [Numpy-discussion] np.in1d() & sets, bug?

really, it is "simply" because ``np.asarray(set([1, 2, 3]))`` returns an object array and 1 is not the same as ``set([1, 2, 3])``. I think earlier numpy versions may have had "short cuts" for short lists or something so this may have wor

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

ing an issue > > on github. Tarballs, installers, and release notes may be found in > > the usual place at Sourceforge. > > > > This looks a bit strange: > It is intentional, it will not be the case in the final release. And thanks Chuck for all the release work!

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote: > On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg > wrote: > > On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote: > >> On 08/11/2015 11:23 PM, Charles R Harris wrote: > >> > Hi All, > >&

Re: [Numpy-discussion] Development workflow (not git tutorial)

We have the `runtests.py` script which will do exactly this (don't think it gives lots of weird warnings normally). I think that is the only real tip I can give. - Sebastian > > What do you recommend: use virtualenvs? Is building inplace the way to > go? Is there a better wa

[Numpy-discussion] Multiarray API size mismatch 301 302?

mismatch 301 302 It is puzzling me, so anyone got a quick idea? - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Multiarray API size mismatch 301 302?

On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote: > Did you do a "git clean -fxd" before re-installing? > Yup. > > On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg > wrote: > Hey, > > just for hacking/

Re: [Numpy-discussion] Multiarray API size mismatch 301 302?

So as Julian helped me, it was the wrong style of the function, the curly bracket has to go on the next line for the API generation to pick it up. - Sebastian On Do, 2015-08-13 at 20:42 +0200, Sebastian Berg wrote: > On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote: > > Did you

Re: [Numpy-discussion] Numpy 1.11

es by the next release. That should be doable, but they are not that explicit goals. Our Austin discussions might have some smaller stuff/wishes that should have some priority. - Sebastian [1] However, I would very much like to see the organizational stuff to be finalized this year. But I kno

Re: [Numpy-discussion] Numpy helper function for __getitem__?

__` work fine, but breaks down if you have advanced indexing involved (or if you return copies, though it spits warnings in that case). - Sebastian > > > ​Stephan > > > > On Sunday, Aug 23, 2015 at 7:54 PM, Fabien > , wrote: > Folks, > >

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

d or even harder to do. But if we can identify this as the "one big thing that gets us 90%" then I refuse to give up hope of doing it in numpy just yet. - Sebastian [1] Travis has said quite a lot about it, but it is not yet clear to me what is a priority/real pain point. Take &quo

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

count its members. Votes and presidents make sense to me for large projects with hundrets of developers on different corners (think of the gnome foundation, debian probably) [1]. One thing I could imagine adding is that the community should be encouraged to ask for/propose new members for the "c

Re: [Numpy-discussion] 1.10.0rc1

ing like: arr = np.zeros((5, 3)) ind = np.array([True, False, False]) arr[ind, :] and numpy nowadays thinks that such code is likely a bug (when the ind is shorter than arr it is somewhat OK, the other way around gets more creepy). If you have an idea of how to make the error m

Re: [Numpy-discussion] 1.10.0rc1

gt; > ind = np.array([True, True, True, False, True]) > > arr[ind] # gives a 4x3 result > > > Running that at the REPL doesn't produce a warning, so i am guessing > that it is valid. > Sure, that is perfect (you can add the slice and write `arr[ind, :]` to make it a

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

mpy ahead. And considering accountability, that help may well amount in saying: "Do NOT do this." A "president" willing to run for such an election, should have a specific vision? Why should they be special to implement it? Note this is also the case in BDFL organizations.

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

ponsible once accepted. I will add one more thing which I think is important: The governance has to be create as little hassle as possible and it should be simple/short enough to quickly understand. - Sebastian > Stéfan > ___ > NumPy-Disc

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

president's job to worry about whether we have vision or not, and do > >> >> >> what they need to, to make sure we don't lose track of that. If > >> >> >> you > >> >> >> don't know it already, I highly recommend Jim Colli

Re: [Numpy-discussion] Numpy FFT.FFT slow with certain samples

If you don't mind the extra dependency or licensing and this is an issue for you, you can try pyfftw (there are likely other similar projects) which wraps fftw and does not have this problem as far as I know. It exposes a numpy-like interface. - sebastian On Fr, 2015-08-28 at 19:13

Re: [Numpy-discussion] np.sign and object comparisons

gt; cases. This is my preferred option. That would be my gut feeling as well. Returning `NaN` could also make sense, but I guess we run into problems since we do not know the input type. So `None` seems like the only option here I can think of right now. - Sebastian > 1. Rai

Re: [Numpy-discussion] np.sign and object comparisons

On Mo, 2015-08-31 at 10:23 -0700, Stephan Hoyer wrote: > On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg > wrote: > That would be my gut feeling as well. Returning `NaN` could > also make > > sense, but I guess we run into problems si

Re: [Numpy-discussion] feature request - increment counter on write check

heck you could check all parents, but you cannot check all children). - Sebastian > Ideally this should be exposed a bit like python's __hash__ method, > lets say __mutablehash__, meaning a hash is returned but be warned > that the object is mutable. For an ndarray, X, containin

Re: [Numpy-discussion] feature request - increment counter on write check

ay be a non-issue, that this design is inherently not quite thread safe. Anyway, I do not know whether or not it is doable or makes sense in numpy right now, just some things to think about. - Sebastian > > -- > View this message in context: > http://numpy-discussion.10968.n7.na

<    1   2   3   4   5   6   7   8   9   >