Re: [Numpy-discussion] numpy.filled, again

On Fri, Jun 14, 2013 at 1:22 PM, Nathaniel Smith wrote: > On Wed, Jun 12, 2013 at 7:43 PM, Eric Firing wrote: > > On 2013/06/12 2:10 AM, Nathaniel Smith wrote: > >> Personally I think that overloading np.empty is horribly ugly, will > >> continue confusing newbies and everyone else indefinitely,

Re: [Numpy-discussion] time to revisit NA/ma ideas

On Fri, Jun 14, 2013 at 6:38 PM, Eric Firing wrote: > A nice summary of the discussions from a year ago is here: > > http://www.numpy.org/NA-overview.html > > It provides food for thought. > > Eric > Perhaps a BoF session should be put together for SciPy 2013, and possibly even have a google han

Re: [Numpy-discussion] Allow == and != to raise errors

I can see where you are getting at, but I would have to disagree. First of all, when a comparison between two mis-shaped arrays occur, you get back a bone fide python boolean, not a numpy array of bools. So if any action was taken on the result of such a comparison assumed that the result was some

Re: [Numpy-discussion] What should be the result in some statistics corner cases?

This is going to need to be heavily documented with doctests. Also, just to clarify, are we talking about a ValueError for doing a nansum on an empty array as well, or will that now return a zero? Ben Root On Mon, Jul 15, 2013 at 9:52 AM, Charles R Harris wrote: > > > On Sun, Jul 14, 2013 at 3

Re: [Numpy-discussion] What should be the result in some statistics corner cases?

On Jul 15, 2013 11:47 AM, "Charles R Harris" wrote: > > > On Mon, Jul 15, 2013 at 8:58 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg < >> sebast...@sipsolutions.net> wrote: >> >>> On Mon, 2013-07-15 at 07:52 -0600, Charles R

Re: [Numpy-discussion] What should be the result in some statistics corner cases?

3:47 -0600, Charles R Harris wrote: >> > On Mon, Jul 15, 2013 at 8:25 AM, Benjamin Root wrote: >> > >> > > This is going to need to be heavily documented with doctests. Also, >> just >> > > to clarify, are we talking about a ValueError for doi

Re: [Numpy-discussion] azip

Forgive my ignorance, but has numpy and scipy stopped doing that weird doc editing thing that existed back in the days of Trac? I have actually held back on submitting doc edits because I hated using that thing so much. ___ NumPy-Discussion mailing list N

Re: [Numpy-discussion] azip

wrote: > 18.07.2013 20:18, Benjamin Root kirjoitti: > > Forgive my ignorance, but has numpy and scipy stopped doing that weird > > doc editing thing that existed back in the days of Trac? I have actually > > held back on submitting doc edits because I hated using that thing so

Re: [Numpy-discussion] fresh performance hits: numpy.linalg.pinv >30% slowdown

On Mon, Jul 22, 2013 at 10:55 AM, Yaroslav Halchenko wrote: > At some point I hope to tune up the report with an option of viewing the > plot using e.g. nvd3 JS so it could be easier to pin point/analyze > interactively. > > shameless plug... the soon-to-be-finalized matplotlib-1.3 has a WebAgg ba

Re: [Numpy-discussion] .flat (was: add .H attribute?)

On Tue, Jul 23, 2013 at 10:11 AM, Stéfan van der Walt wrote: > On Tue, Jul 23, 2013 at 3:39 PM, Alan G Isaac > wrote: > > On 7/23/2013 9:09 AM, Pauli Virtanen wrote: > >> .flat which I think > >> is rarely used > > > Don't assume .flat is not commonly used. A common idiom in matlab is "a[:]" to

Re: [Numpy-discussion] .flat

On Tue, Jul 23, 2013 at 10:46 AM, Pauli Virtanen wrote: > 23.07.2013 17:34, Benjamin Root kirjoitti: > [clip] > > Don't assume .flat is not commonly used. A common idiom in matlab is > > "a[:]" to flatten an array. When porting code over from matlab, it is

Re: [Numpy-discussion] fresh performance hits: numpy.linalg.pinv >30% slowdown

On Mon, Jul 22, 2013 at 1:28 PM, Yaroslav Halchenko wrote: > > On Mon, 22 Jul 2013, Benjamin Root wrote: > > At some point I hope to tune up the report with an option of > viewing the > > plot using e.g. nvd3 JS so it could be easier to pin point/analyze &

Re: [Numpy-discussion] add .H attribute?

On Wed, Jul 24, 2013 at 8:47 AM, Daπid wrote: > An idea: > > If .H is ideally going to be a view, and we want to keep it this way, > we could have a .h() method with the present implementation. This > would preserve the name .H for the conjugate view --when someone finds > the way to do it. > > T

Re: [Numpy-discussion] import overhead of numpy.testing

On Aug 10, 2013 12:50 PM, "Ralf Gommers" wrote: > > > > > On Sat, Aug 10, 2013 at 5:21 PM, Andrew Dalke wrote: >> >> [Short version: It doesn't look like my proposal or any >> simple alternative is tenable.] >> >> On Aug 10, 2013, at 10:28 AM, Ralf Gommers wrote: >> > It does break backwards comp

Re: [Numpy-discussion] import overhead of numpy.testing

On Aug 11, 2013 5:02 AM, "Ralf Gommers" wrote: > > > > > On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root wrote: >> >> Would there be some sort of way to detect that numpy.testing wasn't explicitly imported and issue a deprecation warning? Say, move the co

Re: [Numpy-discussion] import overhead of numpy.testing

On Aug 11, 2013 4:37 PM, "Andrew Dalke" wrote: > > On Aug 11, 2013, at 10:24 PM, Benjamin Root wrote: > > The idea would be that within numpy (and we should fix SciPy as well), we would always import numpy._testing as testing, and not import testing.py ourselves. > >

Re: [Numpy-discussion] RAM problem during code execution - Numpya arrays

On Fri, Aug 23, 2013 at 10:34 AM, Francesc Alted wrote: > Hi José, > > The code is somewhat longish for a pure visual inspection, but my advice > is that you install memory profiler ( > https://pypi.python.org/pypi/memory_profiler). This will help you > determine which line or lines are hugging t

Re: [Numpy-discussion] 1.8.0 branch reminder

On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers wrote: > > > > On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> >> On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> Just a reminder that 1.8.0 will be br

Re: [Numpy-discussion] Array addition inconsistency

On Thu, Aug 29, 2013 at 8:04 AM, Robert Kern wrote: > On Thu, Aug 29, 2013 at 12:00 PM, Martin Luethi > wrote: > > > > Dear all, > > > > After some surprise, I noticed an inconsistency while adding array > > slices: > > > > > a = np.arange(5) > > > a[1:] = a[1:] + a[:-1] > > > a > > array([0, 1,

Re: [Numpy-discussion] Relative speed

On Aug 29, 2013 4:11 PM, "Jonathan T. Niehof" wrote: > > On 08/29/2013 01:48 PM, Ralf Gommers wrote: > > > Thanks. I had read that quite differently, and I'm sure I'm not the only > > one. Some context would have helped > > My apologies--that was a rather obtuse reference. > Just for future r

Re: [Numpy-discussion] Bug (?) converting list to array

The two lists are of different sizes. Had to count twice to catch that. Ben Root On Mon, Sep 9, 2013 at 9:46 AM, Chad Kidder wrote: > I'm trying to enter a 2-D array and np.array() is returning a 1-D array of > lists. I'm using Python (x,y) on Windows 7 with numpy 1.7.1. Here's the > code th

Re: [Numpy-discussion] PEP8

On Sat, Sep 7, 2013 at 7:56 PM, Charles R Harris wrote: > Hi All, > > I've been doing some PEP8 work using autopep8. One problem that has turned > up is that the default behavior of autopep8 is version dependent. I'd like > to put a script in numpy tools that runs autopep8 with some features > dis

Re: [Numpy-discussion] can argmax be used to return row and column indices?

On Fri, Sep 13, 2013 at 4:27 AM, Mark Bakker wrote: > Thanks, Gregorio. > I would like it if argmax had a keyword option to return the row,column > index automatically (or whatever the dimension of the array). > Afterall, argmax already knows the shape of the array. > Calling np.unravel_index( np

Re: [Numpy-discussion] Indexing changes/deprecations

On Fri, Sep 27, 2013 at 8:27 AM, Sebastian Berg wrote: > Hey, > > since I am working on the indexing. I was wondering about a few smaller > things: > > * 0-d boolean array, `np.array(0)[True]` (will work now) would > give np.array([0]) as a copy, instead of the original array. > I guess

Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1

On Wed, Oct 2, 2013 at 11:43 AM, Charles R Harris wrote: > Hi Stefan, > > > On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt wrote: > >> Hi Chuck >> >> On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris >> wrote: >> >> I'll bet the skimage problems come from >> >> https://github.com/numpy/numpy

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 1:05 PM, Charles R Harris wrote: > > > > On Wed, Oct 2, 2013 at 10:56 AM, wrote: > >> On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt >> wrote: >> > On 2 Oct 2013 18:04, "Charles R Harris" >> wrote: >> >> >> >> The question is what to do when all-nan slices are encou

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote: > On 2 Oct 2013 19:14, "Benjamin Root" wrote: > > > > And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) > (ignoring the silly detail that you can't do an equality on nans). > >

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Thu, Oct 3, 2013 at 6:06 AM, Daniele Nicolodi wrote: > Hello, > > sorry, I don't know where exactly jump in in the thread, it is getting > quite long and articulated... > > On 02/10/2013 21:19, Charles R Harris wrote: > > The main problem I had was deciding what arg{max, min} should return as

Re: [Numpy-discussion] Equivalent to IDL's help function

On Mon, Oct 7, 2013 at 1:15 PM, Siegfried Gonzi wrote: > Hi all > > What is the equivalent to IDL its help function, e.g. > > == > IDL> a = make_array(23,23,) > > IDL> help,a > > will result in: > > A FLOAT = Array[23, 23] > > or > > IDL> a = create_struct('idl',23) > > IDL> help

Re: [Numpy-discussion] Using array mask swaps array axes

On Wed, Oct 16, 2013 at 11:39 AM, Chad Kidder wrote: > Just found what should be a bug in 1.7.1. I'm running python(x,y) on > windows here: > > >>> dataMatrix[ii,:,mask].shape > (201, 23) > >>> dataMatrix[ii,:,:].shape > (23, 201) > >>> dataMatrix.shape > (24, 23, 201) > >>> mask > array([ True,

Re: [Numpy-discussion] RuntimeWarning raised in the wrong line

On Wed, Nov 20, 2013 at 9:09 AM, Daπid wrote: > I have the following code, operating on some arrays. > > pen = 1 - (real_sum[int(i1 + t)]) / (absolute[int(i1 + t)]) > if np.isnan(pen): > pen = 0.0 > > I know that, sometimes, real_sum and absolute are 0 at the designated > point, s

Re: [Numpy-discussion] Memory leak in numpy?

Hmmm, I see no reason why that would eat up memory. I just tried it out on my own system (numpy 1.6.1, CentOS 6, python 2.7.1), and had no issues, Memory usage stayed flat for the 10 seconds it took to go through the loop. Note, I am not using ATLAS or BLAS, so maybe the issue lies there? (i don'

Re: [Numpy-discussion] Memory leak?

Just to chime in here about the SciPy Superpack... this distribution tracks the master branch of many projects, and then puts out releases, on the assumption that master contains pristine code, I guess. I have gone down strange rabbit holes thinking that a particular bug was fixed already and the u

Re: [Numpy-discussion] New (old) function proposal.

yes, but I don't like the name too much. Unfortunately, I can't think of a better one. Ben Root On Tue, Feb 18, 2014 at 11:05 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Hi All, > > There is an old ticket, #1499 , > that suggest adding

Re: [Numpy-discussion] Default dtype of genfromtxt

I can certainly see the advantage of switching over to None. It makes a lot of sense. One thing that concerns me, though is a file full of whole number values. Would that get interpreted as integers? If so, then that affect needs to be aligned with some other proposed changes with respect to operat

Re: [Numpy-discussion] except expression discussion on python-ideas

So, this is kind of like Perl's "unless"? On Tue, Feb 18, 2014 at 10:18 PM, Alexander Belopolsky wrote: > I would like to invite numpy community to weigh in on the idea that is > getting momentum at > > https://mail.python.org/pipermail/python-ideas/2014-February/025437.html > > The main motivat

Re: [Numpy-discussion] cPickle.loads and Numeric

Just to echo this sentiment a bit. I seem to recall reading somewhere that pickles are not intended to be long-term archives as there is no guarantee that a pickle made in one version of python would work in another version, much less between different versions of the same (or similar) packages. B

Re: [Numpy-discussion] How security holes happen

And, you know... unit tests to actually know if a the code would reject a spoofed certificate? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] dtype promotion

IIRC, this is dependent on whether you are using 32bit versus 64bit numpy. All regular integer numbers can fit in 32 bits (is that right?), but the 1.1 is treated as a float32 if on a 32 bit NumPy or as float64 if on a 64 bit NumPy. That's my stab at it. Ben Root On Mon, Mar 3, 2014 at 4:06 PM,

Re: [Numpy-discussion] dtype promotion

7;s just a bit > surprising. > > It was convenient to write translations (for a bunch of points) such as: > > Z = np.ones((n,2),dtype=np.float32) + (300,300) > > but I can live with Z += 300,300 > > > Nicolas > > > On 03 Mar 2014, at 23:02, Benjamin Root wrote: > &g

Re: [Numpy-discussion] Standard Deviation (std): Suggested change for "ddof" default value

Because np.mean() is ddof=0? (I mean effectively, not that it actually has a parameter for that) There is consistency within the library, and I certainly wouldn't want to have NaN all of the sudden coming from my calls to mean() that I apply to an arbitrary non-empty array of values that happened t

Re: [Numpy-discussion] ImportError: /usr/local/lib/python2.7/site-packages/numpy-1.8.0-py2.7-linux-x86_64.egg/numpy/core/multiarray.so: undefined symbol: PyUnicodeUCS2_AsASCIIString

Did you rebuild numpy after rebuilding python? Note that if that works, then you will likely need to recompile the entire scipy stack (matplotlib, scipy, etc.). Ben Root On Wed, Apr 16, 2014 at 3:23 PM, jaylene wrote: > Hi, > > I rebuilt the python with -enabled_shared to resolve the following

Re: [Numpy-discussion] arrays and : behaviour

By default, the hold is already True. In fact, that might explain some of the differences in what you are seeing. There are more points in the second image than in the first one, so I wonder if you are seeing some leftovers of previous plot commands? One issue I do see is that the slicing is incor

Re: [Numpy-discussion] Find n closest values

I would echo KDTree, but one way I think you can simplify the existing code you have is to shift the values of L by half the spacing, then you shouldn't need the check for left and right values. Cheers! Ben Root On Sun, Jun 22, 2014 at 4:22 AM, Nicolas P. Rougier < nicolas.roug...@inria.fr> wrot

Re: [Numpy-discussion] Questions about fixes for 1.9.0rc2

Drats... I actually know those two topics... and I might have free time tomorrow afternoon at SciPy. Maybe I could take a peek at it? Ben On Sat, Jul 5, 2014 at 11:24 AM, Sebastian Berg wrote: > On Sa, 2014-07-05 at 00:41 +0100, Nathaniel Smith wrote: > > On 5 Jul 2014 00:07, "Charles R Harris

Re: [Numpy-discussion] Questions about fixes for 1.9.0rc2

I see that a solution has already been found and merged. Are there any remaining issues for matplotlib to resolve? On Sun, Jul 6, 2014 at 2:30 AM, Sebastian Berg wrote: > On Sa, 2014-07-05 at 22:13 -0400, Benjamin Root wrote: > > Drats... I actually know those two topics... and I m

[Numpy-discussion] Cython requirement?

When did Cython become a build requirement? I remember discussing the use of Cython a while back, and IIRC the agreement was that both the cython code and the generated C files would be included in version control so that cython wouldn't be a build requirement, only a developer requirement when mod

[Numpy-discussion] indexed assignment testcases

While trying to wrap my head around the issues with matplotlib's tri module and the new numpy indexing, I have made some test cases where I wonder if warnings should be issued. import numpy as np a = np.ones((10,)) all_false = np.zeros((10,), dtype=bool) a[all_false] = np.array([2.0]) # the shap

Re: [Numpy-discussion] Cython requirement?

Ok, must have missed that discussion. I don't like the reasoning, but that boat has sailed. On Sun, Jul 6, 2014 at 3:00 PM, Robert Kern wrote: > On Sun, Jul 6, 2014 at 7:40 PM, Benjamin Root wrote: > > When did Cython become a build requirement? I remember discussing the > us

Re: [Numpy-discussion] indexed assignment testcases

> > On Sun, Jul 6, 2014 at 1:32 PM, Benjamin Root wrote: > >> While trying to wrap my head around the issues with matplotlib's tri >> module and the new numpy indexing, I have made some test cases where I >> wonder if warnings should be issued. >> >> impo

Re: [Numpy-discussion] indexed assignment testcases

, but now I see that it may be impossible to distinguish from the perfectly normal case. Cheers! Ben Root On Sun, Jul 6, 2014 at 5:48 PM, Nathaniel Smith wrote: > On Sun, Jul 6, 2014 at 9:14 PM, Benjamin Root wrote: > > as for the broadcasting issue, I can see it for the second case

Re: [Numpy-discussion] plt.show() and plt.draw() doesnt work

Please send this question to the matplotlib-users mailing list (if you haven't already, I am still going through a huge backlog). This is the NumPy list. Ben Root On Sat, Jul 12, 2014 at 12:53 PM, Josè Luis Mietta < joseluismie...@yahoo.com.ar> wrote: > Hi experts! > > I have a numpy array M. I

Re: [Numpy-discussion] __numpy_ufunc__

Perhaps a bit of context might be useful? How is numpy_ufunc different from the ufuncs that we know and love? What are the known implications? What are the known shortcomings? Are there ABI and/or API concerns between 1.9 and 1.10? Ben Root On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris wrot

[Numpy-discussion] masked_where broadcasting?

I ran into this this morning while writing up a new test for matplotlib. Shouldn't these two arrays be broadcasted automatically or maybe np.ma is being overly cautious? u = np.ma.masked_where((-0.4 < x) & (x < 0.1), u, copy=False) File "/home/ben/.local/lib/python2.7/site-packages/numpy/ma/

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

I could get behind the context manager approach. It would help keep backwards compatibility, while providing a very easy (and clean) way of consistently using the same reduction operation. Adding kwargs is just a road to hell. Cheers! Ben Root On Sat, Jul 26, 2014 at 9:53 AM, Julian Taylor < jta

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

where a global state would be bad). Ben On Sat, Jul 26, 2014 at 2:29 PM, wrote: > > > > On Sat, Jul 26, 2014 at 9:57 AM, Benjamin Root wrote: > >> I could get behind the context manager approach. It would help keep >> backwards compatibility, while providing a ver

Re: [Numpy-discussion] New function `count_unique` to generate contingency tables.

The ever-wonderful pylab mode in matplotlib has a table function for plotting a table of text in a plot. If I remember correctly, what would happen is that matplotlib's table() function will simply obliterate the numpy's table function. This isn't a show-stopper, I just wanted to point that out. P

Re: [Numpy-discussion] Proposed new feature for numpy.einsum: repeated output subscripts as diagonal

You had me at Kronecker delta... :-) +1 On Thu, Aug 14, 2014 at 3:07 PM, Pierre-Andre Noel < noel.pierre.an...@gmail.com> wrote: > (I created issue 4965 earlier today on this topic, and I have been > advised to email to this mailing list to discuss whether it is a good > idea or not. I include

Re: [Numpy-discussion] Convert 3d NumPy array into 2d

There is also np.squeeze(), which will eliminate any singleton dimensions (but I personally hate using it because it can accidentally squeeze out dimensions that you didn't intend to squeeze when you have arbitrary input data). Ben Root On Wed, Aug 27, 2014 at 11:12 AM, Wagner Sebastian < sebast

Re: [Numpy-discussion] ANN: NumPy 1.9.0 release candidate 1 available

It is generally a good idea when switching between releases to execute "git clean -fxd" prior to rebuilding. Admittedly, I don't know how cleaning out that directory in .local could have impacted things. Go figure. Cheers! Ben Root On Fri, Aug 29, 2014 at 8:50 AM, Neal Becker wrote: > OK, it's

[Numpy-discussion] Can't seem to use np.insert() or np.append() for structured arrays

Consider the following: a = np.array([(1, 'a'), (2, 'b'), (3, 'c')], dtype=[('foo', 'i'), ('bar', 'a1')]) b = np.append(a, (4, 'd')) Traceback (most recent call last): File "", line 1, in File "/home/ben/miniconda/lib/python2.7/site-packages/numpy/lib/function_base.py", line 3555, in append

Re: [Numpy-discussion] inplace unary operations?

Random thoughts are the best kinds of thoughts! I didn't even know there was a np.negative() function! I will keep this card up my sleeve at work for one of those save-the-day moments in optimization. Cheers! Ben Root On Sat, Aug 30, 2014 at 1:45 PM, Nathaniel Smith wrote: > On Sat, Aug 30, 20

Re: [Numpy-discussion] Give Jaime Fernandez commit rights.

Jaime, I had the same feeling when John Hunter gave me commit rights to matplotlib. I later asked him about it, and he said that he gives commit rights to those who annoy the mailing list the most. So, it might not be *that* humbling... :-P Cheers! Ben Root On Wed, Sep 3, 2014 at 9:34 PM, Jaim

Re: [Numpy-discussion] SFMT (faster mersenne twister)

In addition to issues with reproducibility, think of all of the unit tests that would break! On Sun, Sep 7, 2014 at 3:51 PM, Sturla Molden wrote: > "James A. Bednar" wrote: > > > Please don't ever, ever break the sequence of numpy's random numbers! > > Please! We have put a lot of effort into

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

A use case would be "image stitching" or even data tiling. I have had to implement something like this at work (so, I can't share it, unfortunately) and it even goes so far as to allow the caller to specify how much the tiles can overlap and such. The specification is ungodly hideous and I doubt I

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

Btw, on a somewhat related note, whoever can implement ndarray to be able to use views from other ndarrays stitched together would get a fruit basket from me come the holidays and possibly naming rights for the next kid... Cheers! Ben Root On Mon, Sep 8, 2014 at 12:55 PM, Benjamin Root wrote

Re: [Numpy-discussion] Question about broadcasting vs for loop performance

Broadcasting, by itself, should not be creating large arrays in memory. It uses stride tricks to make the array appear larger, while simply reusing the same memory block. This is why it is so valuable because it doesn't make a copy. Now, what may be happening is that the resulting calculation from

Re: [Numpy-discussion] (no subject)

My vote is that NumPy is correct here. I see no reason why >>> float('inf') / 1 and >>> float('inf') // 1 should return different results. Ben Root On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin wrote: > Hello, > Over at Python-ideas, there is a thread [0] about the following > discrepancy:

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

That being said, I do wonder about related situations where the lhs of the equal sign might be an array, or it might be a None and you are comparing against another numpy array. In those situations, you aren't trying to compare against None, you are just checking if two objects are equivalent. Wh

Re: [Numpy-discussion] Custom dtypes without C -- or, a standard ndarray-like type

Travis, Thank you for your perspective on this issue. Such input is always valuable in helping us see where we came from and where we might go. My perspective on NumPy is fairly different, having come into Python right after the whole Numeric/NumArray transition to NumPy. One of the things that r

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

I am also +1. I have already used structured arrays to do keyword-based string formatting. This makes sense as well. Would this enable keyword argument expansion? On Tue, Sep 30, 2014 at 7:29 AM, Eelco Hoogendoorn < hoogendoorn.ee...@gmail.com> wrote: > Sounds fair to me. Indeed the ducktyping ar

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

Actually, if I remember correctly, special methods show up in the ndarray object when the dtype is datetime64, right? On Wed, Oct 1, 2014 at 10:13 AM, Eelco Hoogendoorn < hoogendoorn.ee...@gmail.com> wrote: > Well, the method will have to be present on all ndarrays, since structured > arrays do n

Re: [Numpy-discussion] 0/0 == 0?

Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions? Ben Root On Oct 2, 2014 7:02 PM, "T J" wrote: > Hi, I'm using NumPy 1.8.2: > > In [1]: np.array(0) / np.array(0) > Out[1]: 0 > > In

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

I have a need to "and" together an arbitrary number of boolean arrays. np.logical_and() expects only two positional arguments. There has got to be some sort of easy way to just and these together using the ufunc mechanism, right? Cheers! Ben Root ___ Num

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

: > On Fri, Oct 10, 2014 at 11:23 AM, Benjamin Root wrote: > >> I have a need to "and" together an arbitrary number of boolean arrays. >> np.logical_and() expects only two positional arguments. There has got to be >> some sort of easy way to just and these together u

Re: [Numpy-discussion] numpy.mean slicing in a netCDF file

Stephen is being a bit modest by putting xray last in the list. I recommend it, and it is very painless to install. I could only get iris installed via a SciTools repo on binstar and even then, I had to tinker with a few things to get it working (and it was only the linux binaries, too). Ben Root

Re: [Numpy-discussion] Changed behavior of np.gradient

It isn't really a question of accuracy. It breaks unit tests and reproducibility elsewhere. My vote is to revert to the old behavior in 1.9.1. Ben Root On Thu, Oct 16, 2014 at 6:10 PM, Ariel Rokem wrote: > > On Thu, Oct 16, 2014 at 10:22 AM, Nathaniel Smith wrote: > >> On Tue, Oct 14, 2014 at

Re: [Numpy-discussion] Changed behavior of np.gradient

;t testing numpy 1.9 at the time. I want the feature (I have need for it elsewhere), but I don't want the change in default behavior. Cheers! Ben Root On Thu, Oct 16, 2014 at 9:31 PM, Nathaniel Smith wrote: > On Fri, Oct 17, 2014 at 2:23 AM, Benjamin Root wrote: > > It isn'

Re: [Numpy-discussion] Changed behavior of np.gradient

I see this as a regression. We don't keep regressions around for backwards compatibility, we fix them. Ben On Thu, Oct 16, 2014 at 10:25 PM, Matthew Brett wrote: > Hi, > > On Thu, Oct 16, 2014 at 6:38 PM, Benjamin Root wrote: > > That isn't what I meant. Higher o

Re: [Numpy-discussion] Memory efficient alternative for np.loadtxt and np.genfromtxt

As a bit of an aside, I have just discovered that for fixed-width text data, numpy's text readers seems to edge out pandas' read_fwf(), and numpy has the advantage of being able to specify the dtypes ahead of time (seems that the pandas version just won't allow it, which means I end up with float64

Re: [Numpy-discussion] Deprecate pkgload, PackageLoader

/me looks at pydoc numpy.pkgload What in the world?! On Wed, Oct 29, 2014 at 7:12 AM, Robert Kern wrote: > On Wed, Oct 29, 2014 at 4:30 AM, Charles R Harris > wrote: > > Hi All, > > > > It is proposed to deprecate, then remove, pkgload and PackageLoader. > > > > Complaints? Cries of Anguish? >

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

Just to throw in my two cents here. I feel that sometimes, features are tried out first elsewhere (possibly in scipy) and then brought down into numpy after sufficient shakedown time. So, in some cases, I wonder if the numpy version is actually more refined than the scipy version? Of course, there

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

FWIW, matplotlib calls it "low hanging fruit". I think it is a better name than "newcomers". On Wed, Nov 26, 2014 at 1:19 PM, Aldcroft, Thomas < aldcr...@head.cfa.harvard.edu> wrote: > > > On Wed, Nov 26, 2014 at 8:24 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Wed, N

Re: [Numpy-discussion] Updates on NA / NaN values for Ints?

That being said, doesn't Pandas support something like what you are asking for? While Pandas would like to push the NA support down into the NumPy level for seamless interaction with other SciPy libraries, it does a very decent job with NA on its own, and depending on the sort of code you need to w

Re: [Numpy-discussion] Updates on NA / NaN values for Ints?

> integrate it with dynd. > > (ha! good catch Nathaniel -- sorry for double dipping, Internet initially > suggested they were waiting to see what the numpy team would do) > > On Fri Nov 28 2014 at 5:52:19 PM Benjamin Root wrote: > >> That being said, doesn't Pandas suppo

Re: [Numpy-discussion] Finding values in an array

If we don't have an operation for this in numpy's setops module, it probably should be added. Ben Root On Nov 28, 2014 10:21 PM, "Jaime Fernández del Río" wrote: > On Fri, Nov 28, 2014 at 5:15 PM, Nathaniel Smith wrote: > >> On Fri, Nov 28, 2014 at 3:15 AM, Alexander Belopolsky >> wrote: >> >

Re: [Numpy-discussion] taking a 2D uneven surface slice

A slightly different way to look at it (I don't think it is exactly the same problem, but the description reminded me of it): http://mail.scipy.org/pipermail/numpy-discussion/2013-April/066269.html (and I think there are some things that can be done to make that faster, but I don't recall it righ

Re: [Numpy-discussion] taking a 2D uneven surface slice

I am sorry, I meant to post this in a different thread... On Wed, Dec 3, 2014 at 8:32 PM, Benjamin Root wrote: > A slightly different way to look at it (I don't think it is exactly the > same problem, but the description reminded me of it): > > http://mail.scipy.org/pipermail

Re: [Numpy-discussion] slicing an n-dimensional array

Posting in the correct thread now... A slightly different way to look at it (I don't think it is exactly the same problem, but the description reminded me of it): http://mail.scipy.org/pipermail/numpy-discussion/2013-April/066269.html (and I think there are some things that can be done to make tha

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

I like the idea of the broadcast argument to reshape. It certainly makes sense there, and it avoids adding a new function. Probably should add a note to the docstring of broadcast_arrays, too. Ben Root On Mon, Dec 8, 2014 at 2:31 AM, Pierre Haessig wrote: > Hi, > > Le 07/12/2014 08:10, Stephan

Re: [Numpy-discussion] Why is numpy.ma.extras.clump_masked() not in main documentation?

Wow, thanks for pointing these out! I have been using masked arrays for quite a while now, but I never noticed these before! Cheers! Ben Root On Sun, Dec 28, 2014 at 3:35 PM, Yuxiang Wang wrote: > Hi Ralf, > > Thanks for the quick response! I will submit a PR soon. I noticed > there are some o

Re: [Numpy-discussion] Clarifications in numpy.ma module

What do you mean that the mean function doesn't take care of the case where the array is empty? In the example you provided, they both end up being NaN, which is exactly correct. Ben Root On Tue, Dec 30, 2014 at 6:10 AM, Maniteja Nandana < maniteja.modesty...@gmail.com> wrote: > Guys, > sorry fo

Re: [Numpy-discussion] Clarifications in numpy.ma module

something that should be address in some form. Ben Root On Tue, Dec 30, 2014 at 2:39 PM, Alexander Belopolsky wrote: > > On Tue, Dec 30, 2014 at 1:45 PM, Benjamin Root wrote: > >> What do you mean that the mean function doesn't take care of the case >> where the array is

Re: [Numpy-discussion] Clarifications in numpy.ma module

On Tue, Dec 30, 2014 at 3:29 PM, Alexander Belopolsky wrote: > On Tue, Dec 30, 2014 at 2:49 PM, Benjamin Root wrote: > >> Where does it say that operations on masked arrays should not produce >> NaNs? > > > Masked arrays were invented with the specific goal

Re: [Numpy-discussion] Clarifications in numpy.ma module

exception? Did you mean warning? If warning, I recall some discussion recently to figure out a way to hide that, but only for masked values (I would want to see the warning if I do bad calculations in the unmasked portions of my array). Now I see your point 3 much more clearly. I had never noticed

Re: [Numpy-discussion] Clarifications in numpy.ma module

at 6:34 PM, Maniteja Nandana < maniteja.modesty...@gmail.com> wrote: > > On 31-Dec-2014 4:53 am, "Nathaniel Smith" wrote: > > > > On Tue, Dec 30, 2014 at 10:56 PM, Benjamin Root wrote: > > > exception? Did you mean warning? If warning, I recall some discu

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] Regarding np.ma.masked_equal behavior

Personally, I have never depended upon an implicit fill value. I would always handle it explicitly. Off the top of my head, a project that might have really good insight into how fill_value should work is the python-netCDF4 project (so, talk to Jeff Whitaker, I think), and/or the HDF5 people. I kno

Re: [Numpy-discussion] linspace handling of extra return

Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though. Cheers! Ben Root On Tue, Jan 13, 2015 a

Re: [Numpy-discussion] linspace handling of extra return

So, raise a ValueError when it used to return (mostly) correct results? For some reason, I don't think people would appreciate that. Ben Root On Jan 13, 2015 5:59 PM, "Chris Barker" wrote: > On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root wrote: > >> Oh, wow. I neve

<    1   2   3   4   5   6   7   >