[Numpy-discussion] Set FutureWarnings to error in (dev) tests?

]. Anyway, should we attempt to do this? I admit that trying to make it work, even *with* the change FutureWarnings suddenly pop up when you make the warnings being given less often (I will guess that warning was already issued at import time somewhere). - Sebastian [1] And at that a brand new future

Re: [Numpy-discussion] Behavior of np.random.uniform

On Do, 2016-01-21 at 09:38 +, Robert Kern wrote: > On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > > > On Di, 2016-01-19 at 16:28 +, G Young wrote: > > > In rand range, it raises an exception if low >= high

Re: [Numpy-discussion] Behavior of np.random.uniform

somewhere, it could be different): >>> np.random.set_state(('MT19937', random.getstate()[1][:-1], >>> random.getstate()[1][-1])) Will enable you to draw the same numbers with random.uniform and np.random.uniform. - Sebastian > Greg > > On Tue, Jan 19,

Re: [Numpy-discussion] Get rid of special scalar arithmetic

l that, but to me it is not obvious that it would be the best thing to get rid of scalars completly (getting rid of the code duplication is a different issue). - Sebastian > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org

Re: [Numpy-discussion] ENH: Add the function 'expand_view'

e, we could maybe even mention the combination in the examples (i.e. broadcast_to example?). - Sebastian > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion >

Re: [Numpy-discussion] Proposal for a new function: np.moveaxis

Just a heads up, I am planning to put in Stephans pull request (more info, see original mail below) as soon as some minor things are cleared. So if you have any objections or better ideas for the name, now is the time. - Sebastian On Mi, 2015-11-04 at 23:42 -0800, Stephan Hoyer wrote: > I

Re: [Numpy-discussion] what would you expect A[none] to do?

xis` with `np.newaxis is None` for the same thing. `None` inserts a new axes, it is documented to do so in the indexing documentation, so I will ask you to check it if you have more questions. If you want a noop, you should probably use `...` or `Ellipsis`. - Sebastian > __

Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?

On Mi, 2015-12-30 at 20:21 +0100, Nicolas P. Rougier wrote: > In the end, I’ve only the list comprehension to work as expected > > A = [0,0,1,3] > B = np.arange(8) > np.random.shuffle(B) > I = [list(B).index(item) for item in A if item in B] > > > But Mark's and Sebastian's methods do not seem t

Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?

id] = -1 # mark invalids with -1 In [73]: B_index Out[73]: array([ 2, 0, 1, -1]) Anyway, I guess the arrays would likely have to be quite large for this to beat list comprehension. And maybe doing the searchsorted the other way around could be faster, no idea. - Sebastian > > Nicolas >

Re: [Numpy-discussion] Dynamic array list implementation

hon, but pythons buildin array.array should get you there pretty much as well. Of course it requires the C typecode (though that should not be hard to get) and does not support strings. - Sebastian > > In my experience, it's several times faster than using a builtin list > from Cython,

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

lready, last release with 2.7 was in October. More details on download rates (but unfortunately without absolute numbers) here: http://sourceforge.net/projects/winpython/files/ Sebastian -- python programming - mail server - photo - video - https://sebix.at To verify my cryptographic signature or s

Re: [Numpy-discussion] numpy.power -> numpy.random.choice Probabilities don't sum to 1

to do kahan summation, however, I think it always assumes double precision for the p keyword argument, so as a work around at least, you have to sum to convert to and normalize it as double. - Sebastian > > On Fri, Dec 18, 2015 at 7:00 PM, Nathaniel Smith > wrot

[Numpy-discussion] Introducing outer/orthonongal indexing to numpy

ibutes into 1.11. So if you are interested in teaching and have suggestions for the names, or have thoughts about subclasses, or... please share your thoughts! :) Regards, Sebastian signature.asc Description: This is a digitally signed message part __

Re: [Numpy-discussion] array_equal too strict?

[3.14159265358979329], > dtype=numpy.float64 > ) > ``` > (differing the in the 18th overall digit) are reported equal by > array_equal: If you have some spare cycles, maybe you can open a pull request to add np.isclose to the "See Also" section? - Sebastian

Re: [Numpy-discussion] Why does np.repeat build a full array?

On Di, 2015-12-15 at 08:56 +0100, Sebastian Berg wrote: > On Di, 2015-12-15 at 17:49 +1100, Juan Nunez-Iglesias wrote: > > Hi, > > > > > > I've recently been using the following pattern to create arrays of a > > specific repeating value: > >

Re: [Numpy-discussion] Why does np.repeat build a full array?

e, but they can also be unexpected/inconsistent when you start writing to the result array, so you should not do it (and the array should preferably be read-only IMO, as_strided itself does not do that). But yes, there might be room for a function or so to make some stride t

Re: [Numpy-discussion] Memory mapping and NPZ files

and could raise an error which suggests to manually uncompress the file when mmap_mode is given. - Sebastian > Can somebody confirm that? > > If I'm correct, the mmap_mode argument could be passed to the NpzFile > class which could in turn perform the correct operation. One way to &

Re: [Numpy-discussion] array of random numbers fails to construct

> +1. Not a high priority, but it would be nice. Opened an issue for this: https://github.com/numpy/numpy/issues/6790 > Warren Sebastian signature.asc Description: OpenPGP digital signature ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Inconsistent/unexpected indexing semantics

lice_object[2] = 3 >>> arr[slice_object] and all of this code (numpy also has a lot of it), will probably have to change the last line to be: >>> arr[tuple(slice_object)] So the implication of this might actually be more farther reaching then one might think at first; or at le

Re: [Numpy-discussion] Indexing NEP draft

warnings; warnings.simplefilter("always") The examples from the NEP at should all run fine, you can find the NEP draft at: https://github.com/numpy/numpy/pull/6256/files?short_path=01e4dd9#diff-01e4dd9d2ecf994b24e5883f98f789e6 I would be most happy about any comments or suggestions!

Re: [Numpy-discussion] understanding buffering done when broadcasting

On Di, 2015-11-24 at 16:49 -0800, Eli Bendersky wrote: > > > On Mon, Nov 23, 2015 at 2:09 PM, Sebastian Berg > wrote: > On Mo, 2015-11-23 at 13:31 -0800, Eli Bendersky wrote: > > Hello, > > > > > > I'm trying t

Re: [Numpy-discussion] understanding buffering done when broadcasting

o have a look ;). The code is not the most read one in NumPy, and it would not surprise me a lot if you can find something to tweak. - Sebastian > > If I instrument Numpy (setting NPY_IT_DBG_TRACING and such), I see > that when the add() ufunc is called, 'n' is copied into a t

Re: [Numpy-discussion] reshaping array question

On Di, 2015-11-17 at 13:49 -0500, Neal Becker wrote: > Robert Kern wrote: > > > On Tue, Nov 17, 2015 at 3:48 PM, Neal Becker wrote: > >> > >> I have an array of shape > >> (7, 24, 2, 1024) > >> > >> I'd like an array of > >> (7, 24, 2048) > >> > >> such that the elements on the last dimension are

Re: [Numpy-discussion] reshaping array question

arr_r = arr.transpose((0, 1, 3, 2)) arr_r = arr_r.reshape((7, 24, -1)) - Sebastian > [0,0,0,0] -> [0,0,0] > [0,0,1,0] -> [0,0,1] > [0,0,0,1] -> [0,0,2] > [0,0,1,1] -> [0,0,3] > ... > > What might be the simplest way to do this? > > > A differ

Re: [Numpy-discussion] loadtxt and usecols

against the flattening and even the array-like logic [1] currently in the PR, it seems like arbitrary generality for my taste without any obvious application. As said before, the other/additional thing that might be very helpful is trying to give a more useful error message. - Sebastian [1] Al

[Numpy-discussion] Indexing NEP draft

e very welcome, and if it is "I don't understand a word" :). I know it is probably too short and, at least without examples, not easy to understand. Best, Sebastian =

Re: [Numpy-discussion] loadtxt and usecols

d only suggest that you also accept buffer interface objects or array_interface stuff. Which in this case is really unnecessary I think. - Sebastian > > Ben Root > > > On Tue, Nov 10, 2015 at 10:07 AM, Irvin Probst > wrote: > On 10/11/2015 14:17, Sebastian Berg

Re: [Numpy-discussion] loadtxt and usecols

On Di, 2015-11-10 at 10:24 +0100, Irvin Probst wrote: > On 10/11/2015 09:19, Sebastian Berg wrote: > > since a scalar row (so just one row) is read and not a 2D array. I tend > > to say it should be an array-like argument and not a generalized > > sequence argument, just wante

Re: [Numpy-discussion] loadtxt and usecols

t by broadcasting between `1` and `(1,)` analogous to indexing the full array with usecols: usecols=1 result: array([2, 3, 4, 5]) usecols=(1,) result [1]: array([[2, 3, 4, 5]]) since a scalar row (so just one row) is read and not a 2D array. I tend to say it should be an array-like argument and n

Re: [Numpy-discussion] isfortran compatibility in numpy 1.10.

I bet it has all been said already, but to note just in case. In numpy itself we use it mostly to determine the memory order of the *output* and not for safty purpose. That is the macro of course and I think yelling people to use flags.fnc in python is better. - Sebastian On Mon Nov 2 08:52

Re: [Numpy-discussion] Commit rights for Jonathan J. Helmus

Congrats, both of you ;). On Sun Nov 1 04:30:27 2015 GMT+0330, Jaime Fernández del Río wrote: > "Gruetzi!", as I just found out we say in Switzerland... > On Oct 30, 2015 8:20 AM, "Jonathan Helmus" wrote: > > > On 10/28/2015 09:43 PM, Allan Haldane wrote: > > > On 10/28/2015 05:27 PM, Nathanie

Re: [Numpy-discussion] when did column_stack become C-contiguous?

s change of the output order in advanced indexing in some cases, it makes it faster sometimes, and probably slower in others, what is right seems very much non-trivial. - Sebastian > > >>> np.column_stack((np.ones(10), np.ones((10, 2), order='F'))).flags > C_CONTIGUOUS : F

Re: [Numpy-discussion] Numpy 1.10.0 release

y first guess would be, that it sounds like you got some old test files flying around. Can you try cleaning up everything and reinstall? It can happen that old installed test files survive the new version. And most of all, thanks a lot Chuck! - Sebastian > >

Re: [Numpy-discussion] Sign of NaN

n being careful to implement all possible features ;). It is not that I think we would not have consistent rules, etc. it is just that we *want* to force code to be obvious. If someone has arrays inside arrays, maybe he should be expected to specify that. It actually breaks some logic (or cannot be i

Re: [Numpy-discussion] Sign of NaN

On Mi, 2015-09-30 at 00:01 -0700, Nathaniel Smith wrote: > On Tue, Sep 29, 2015 at 2:07 PM, Sebastian Berg > wrote: > > On Di, 2015-09-29 at 11:16 -0700, Nathaniel Smith wrote: > [...] > >> In general I'm not a big fan of trying to do all kinds of guessing > >&

Re: [Numpy-discussion] Sign of NaN

d some way to tell that numpy as a PyDecimalDtype. Now "object" would possibly be just a fallback to mean "figure out what to use for each element". It would be a bit slower, but it would work very generally, because numpy would not impose limits as such. - Sebastian > OTOH s

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

nt rules and do not like exceptions much. As I said, I will not get in the way of any consensus saying otherwise though and I am sure there are many ways to change the current draft that even I will like ;)! - Sebastian > > I think this addresses most of the concerns, IBM is happy (eno

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

On Mi, 2015-09-23 at 19:48 -0500, Travis Oliphant wrote: > > > On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris > wrote: > > > On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker > wrote: > On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant >

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

On Do, 2015-09-24 at 10:03 -0700, Nathaniel Smith wrote: > On Sep 24, 2015 4:14 AM, "Sebastian Berg" > wrote: > > > > On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote: > > > On 2015-09-24 00:17:33, Jens Jørgen Mortensen > wrote: > > &

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

On Do, 2015-09-24 at 10:45 +0200, Sebastian Berg wrote: > On Do, 2015-09-24 at 00:22 -0700, Nathaniel Smith wrote: > > On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant > > wrote: > > >> > > >> Here is a list of the current Contributors to the main NumPy

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

On Do, 2015-09-24 at 13:14 +0200, Sebastian Berg wrote: > On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote: > > On 2015-09-24 00:17:33, Jens Jørgen Mortensen wrote: > > > jensj@jordan:~$ python > > > Python 2.7.9 (default, Apr 2 2015, 15:33:21) > > &

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

should then be ravelled, so this is indeed a bug. > > If I bisected correctly, the problematic change is this one: > Hmmm, unless we want to make sure that the output of ravel is always contiguous (which would be a difference from `.reshape(-1)`. It would be a bit safer, and not a usel

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

should then be ravelled, so this is indeed a bug. > > If I bisected correctly, the problematic change is this one: > Yeah, vdot uses `ravel`. That is correct, but it should only use it after making sure the input is C-order, or make sure the output of ravel is C-order (vdot was changed t

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

ight in to keep the current times but do not feel very strongly. About using the commit log to seed, I think there are some old term contributers (David Cournapeau maybe?), who never stopped doing quite a bit but may not have merge commits. However, I think we can start of with what we had, then I w

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

nk we should include some relation to historic contributions into the document. I think what might be nice to do would be for example to also "seed" the emeritus list (if it is not too difficult). It is somewhat unrelated to governance, but since we want it to be a prominent document, it

Re: [Numpy-discussion] Governance model request

icitely in governance. I am aware that everyone wants to help, but right now I do not feel helped at all :). - Sebastian > Sorry if that means more work for you Fernando, because I know that you > have become a very busy person, but I also know how much do you care about > the NumPy

[Numpy-discussion] Steering Committee Size

old time contributers who were not active in the past year(s). I cannot form/change my opinion based on the previous discussion, because I would like to get an idea of how everyone feels about these points first. Then we can fight about details :) - Sebastian (sending from phone, so sorry about

Re: [Numpy-discussion] Governance model request

ng about ABI" it may sound like "two years from now we will definitely break ABI", the curse being that it does not matter that you and those who know numpy's well know that it is just you stressing strongly that we should seriously discuss it. I have to admit, you sometimes sound a

Re: [Numpy-discussion] Governance model request

On Mo, 2015-09-21 at 11:32 +0200, Sebastian Berg wrote: > On So, 2015-09-20 at 11:20 -0700, Travis Oliphant wrote: > > After long conversations at BIDS this weekend and after reading the > > entire governance document, I realized that the steering council is > > very large a

Re: [Numpy-discussion] Governance model request

neither of your three options feel very obvious to me unfortunately. - Sebastian > A one year time frame is pretty short on the context of a two decades > old project and I believe the current council has too few people who > have been around the community long enough to help unstuck d

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

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] 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] 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] 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] 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] 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)

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] 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] 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] 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] 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] 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] 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] 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] 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/

[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] 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

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] [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] 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] 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] 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] 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.?

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] 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] 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

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] 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] 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?

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] floats for indexing, reshape - too strict ?

here makes any good. Python is also strong-typed which means that types are never converted silently. I think a library should follow the behavior of the language. https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language Sebastian -

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] Removal of Deprecated Keywords/functionality

dtxt that allows skipping a header or other data at the beginning, which do not start with #. This is often the case with data from measurement device and software. Sometimes these lines are also used to give informations about the circumstances or the probe in a non-CSV and non-tab-separated s

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] 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] 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] 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] 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] 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

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] 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] 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] 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] 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] 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 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 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

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

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? > >

<    1   2   3   4   5   6   7   8   9   >