Re: [Numpy-discussion] Bug

Sorry, wrong shortcut key, question will arrive later. Josef On Fri, Oct 16, 2015 at 1:40 PM, wrote: > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

Agreed that indexing functions should return bare `ndarray`. Note that in Jaime's PR one can override it anyway by defining __nonzero__. -- Marten On Sat, May 9, 2015 at 9:53 PM, Stephan Hoyer wrote: > With regards to np.where -- shouldn't where be a ufunc, so subclasses or > other array-likes

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

With regards to np.where -- shouldn't where be a ufunc, so subclasses or other array-likes can be control its behavior with __numpy_ufunc__? As for the other indexing functions, I don't have a strong opinion about how they should handle subclasses. But it is certainly tricky to attempt to handl

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

On Sat, May 9, 2015 at 1:27 PM, Benjamin Root wrote: > > On Sat, May 9, 2015 at 4:03 PM, Nathaniel Smith wrote: >> >> Not sure what this has to do with Jaime's post about nonzero? There is >> indeed a potential question about what 3-argument where() should do with >> subclasses, but that's effect

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

On Sat, May 9, 2015 at 4:03 PM, Nathaniel Smith wrote: > Not sure what this has to do with Jaime's post about nonzero? There is > indeed a potential question about what 3-argument where() should do with > subclasses, but that's effectively a different operation entirely and to > discuss it we'd n

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

On May 9, 2015 12:54 PM, "Benjamin Root" wrote: > > Absolutely, it should be writable. As for subclassing, that might be messy. Consider the following: > > inds = np.where(data > 5) > > In that case, I'd expect a normal, bog-standard ndarray because that is what you use for indexing (although pand

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

Absolutely, it should be writable. As for subclassing, that might be messy. Consider the following: inds = np.where(data > 5) In that case, I'd expect a normal, bog-standard ndarray because that is what you use for indexing (although pandas might have a good argument for having it return one of t

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

On May 9, 2015 10:48 AM, "Jaime Fernández del Río" wrote: > > There is a reported bug (issue #5837) regarding different returns from np.nonzero with 1-D vs higher dimensional arrays. A full summary of the differences can be seen from the following output: > > >>> class C(np.ndarray): pass > ... >

Re: [Numpy-discussion] Bug in 1.9?

On Wed, Oct 22, 2014 at 12:28 PM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > On 22.10.2014 20:00, Charles R Harris wrote: > > > > > > On Wed, Oct 22, 2014 at 11:32 AM, Neil Girdhar > > wrote: > > > > Hello, > > > > Is this desired behaviour or a

Re: [Numpy-discussion] Bug in 1.9?

On 22.10.2014 20:00, Charles R Harris wrote: > > > On Wed, Oct 22, 2014 at 11:32 AM, Neil Girdhar > wrote: > > Hello, > > Is this desired behaviour or a regression or a bug? > > > http://stackoverflow.com/questions/26497656/how-do-i-align-a-numpy-rec

Re: [Numpy-discussion] Bug in 1.9?

On Wed, Oct 22, 2014 at 11:32 AM, Neil Girdhar wrote: > Hello, > > Is this desired behaviour or a regression or a bug? > > > http://stackoverflow.com/questions/26497656/how-do-i-align-a-numpy-record-array-recarray > > Thanks, > I'd guess that the definition of aligned may have become stricter, t

Re: [Numpy-discussion] Bug in genfromtxt with usecols and converters

On 26 Aug 2014, at 09:05 pm, Adrian Altenhoff wrote: >> But you are right that the problem with using the first_values, which should >> of course be valid, >> somehow stems from the use of usecols, it seems that in that loop >> >>for (i, conv) in user_converters.items(): >> >> i in user_c

Re: [Numpy-discussion] Bug in genfromtxt with usecols and converters

Hi Derek, > But you are right that the problem with using the first_values, which should > of course be valid, > somehow stems from the use of usecols, it seems that in that loop > > for (i, conv) in user_converters.items(): > > i in user_converters and in usecols get out of sync. This cert

Re: [Numpy-discussion] Bug in genfromtxt with usecols and converters

Hi Adrian, >> not sure whether to call it a bug; the error seems to arise before reading >> any actual data >> (even on reading from an empty string); when genfromtxt is checking the >> filling_values used >> to substitute missing or invalid data it is apparently testing on default >> testing v

Re: [Numpy-discussion] Bug in genfromtxt with usecols and converters

Hi Derek, thanks for your answer. > not sure whether to call it a bug; the error seems to arise before reading > any actual data > (even on reading from an empty string); when genfromtxt is checking the > filling_values used > to substitute missing or invalid data it is apparently testing on def

Re: [Numpy-discussion] Bug in genfromtxt with usecols and converters

Hi Adrian, > I tried to load data from a csv file into numpy using genfromtxt. I need > only a subset of the columns and want to apply some conversions to the > data. attached is a minimal script showing the error. > In brief, I want to load columns 1,2 and 4. But in the converter > function for t

Re: [Numpy-discussion] Bug in np.cross for 2D vectors

> Hi, > > We came across this bug while using np.cross on 3D arrays of 2D vectors. > > What version of numpy are you using? This should already be solved in numpy > master, and be part of the 1.9 release. Here's the relevant commit, > although the code has been cleaned up a bit in later ones: >

Re: [Numpy-discussion] Bug in np.cross for 2D vectors

> Hi, > > We came across this bug while using np.cross on 3D arrays of 2D vectors. > > What version of numpy are you using? This should already be solved in numpy > master, and be part of the 1.9 release. Here's the relevant commit, > although the code has been cleaned up a bit in later ones: > h

Re: [Numpy-discussion] Bug in np.cross for 2D vectors

On Di, 2014-07-15 at 10:22 +0100, Neil Hodgson wrote: > Hi, > > We came across this bug while using np.cross on 3D arrays of 2D > vectors. Hi, which numpy version are you using? Until recently, the cross product simply did *not* work in a broadcasting manner (3d arrays of 2d vectors), it did som

Re: [Numpy-discussion] Bug in np.cross for 2D vectors

On Tue, Jul 15, 2014 at 2:22 AM, Neil Hodgson wrote: > Hi, > > We came across this bug while using np.cross on 3D arrays of 2D vectors. > What version of numpy are you using? This should already be solved in numpy master, and be part of the 1.9 release. Here's the relevant commit, although the c

Re: [Numpy-discussion] bug in comparing object arrays to None (?)

On Mon, Jan 27, 2014 at 3:43 PM, Charles G. Waldman wrote: > Hi Numpy folks. > > I just noticed that comparing an array of type 'object' to None does > not behave as I expected. Is this a feature or a bug? (I can take a > stab at fixing it if it's a bug, as I believe it is). > > >>> np.version.f

Re: [Numpy-discussion] Bug in numpy.correlate documentation

On 11.10.2013, at 01:19, Julian Taylor wrote: >>> >>>Yeah, unless the current behaviour is actually broken or redundant in >>>some way, we're not going to switch from one perfectly good convention >>>to another perfectly good convention and break everyone's code in the >>>process

Re: [Numpy-discussion] Bug in numpy.correlate documentation

On 10.10.2013 21:31, Bernhard Spinnler wrote: > > On 10.10.2013, at 19:27, David Goldsmith > wrote: >> >> On Wed, Oct 9, 2013 at 7:48 PM, Bernhard Spinnler >> mailto:bernhard.spinn...@gmx.net>> wrote: >> > Hi Richard, >> > >> > Ah, I searched th

Re: [Numpy-discussion] Bug in numpy.correlate documentation

On 10.10.2013, at 19:27, David Goldsmith wrote: > On Wed, Oct 9, 2013 at 7:48 PM, Bernhard Spinnler > wrote: > > Hi Richard, > > > > Ah, I searched the list but didn't find those posts before? > > > > I can easily imagine that correlation is defined differently in different > > disciplines. Both

Re: [Numpy-discussion] Bug in numpy.correlate documentation

It seems to me that Wolfram is following yet another path. From http://mathworld.wolfram.com/Autocorrelation.html and more importantly http://mathworld.wolfram.com/Cross-Correlation.html, equation (5): z_mathworld[k] = sum_n conj(a[n]) * v[n+k] = conj( sum_n a[n] * conj(v[n+k]) )

Re: [Numpy-discussion] Bug in numpy.correlate documentation

Date: Wed, 9 Oct 2013 21:54:07 +0100 > From: Nathaniel Smith > Subject: Re: [Numpy-discussion] Bug in numpy.correlate documentation > To: Discussion of Numerical Python > Message-ID: > z8v-ahuu+85lz88xywmawxgzhk5ghtfuw8h...@mail.gmail.com> > Content-Type: text

Re: [Numpy-discussion] Bug in numpy.correlate documentation

On Wed, Oct 9, 2013 at 7:48 PM, Bernhard Spinnler wrote: > Hi Richard, > > Ah, I searched the list but didn't find those posts before… > > I can easily imagine that correlation is defined differently in different > disciplines. Both ways are correct and it's just a convention or definition. > In m

Re: [Numpy-discussion] Bug in numpy.correlate documentation

athworld.wolfram.com/Autocorrelation.html DG Date: Tue, 8 Oct 2013 20:10:41 +0100 > From: Richard Hattersley > Subject: Re: [Numpy-discussion] Bug in numpy.correlate documentation > To: Discussion of Numerical Python > Message-ID: > f...@mail.gmail.com> > Content-Type

Re: [Numpy-discussion] Bug in numpy.correlate documentation

Hi Richard, Ah, I searched the list but didn't find those posts before… I can easily imagine that correlation is defined differently in different disciplines. Both ways are correct and it's just a convention or definition. In my field (Digital Communications, Digital Signal Processing) the vast

Re: [Numpy-discussion] Bug in numpy.correlate documentation

Hi Bernard, Looks like you're on to something - two other people have raised this discrepancy before: https://github.com/numpy/numpy/issues/2588. Unfortunately, when it comes to resolving the discrepancy one of the previous comments takes the opposite view. Namely, that the docstring is correct an

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

On 9 Sep 2013 15:50, wrote: > > On Mon, Sep 9, 2013 at 9:52 AM, Nathaniel Smith wrote: > > One list has 6 entries and one has 7, so they can't be aligned into a single > > array. Possibly it would be better to raise an error here instead of > > returning an object array, but that's what's going o

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

On Mon, Sep 9, 2013 at 11:35 AM, Nathaniel Smith wrote: > On 9 Sep 2013 15:50, wrote: >> >> On Mon, Sep 9, 2013 at 9:52 AM, Nathaniel Smith wrote: >> > One list has 6 entries and one has 7, so they can't be aligned into a >> > single >> > array. Possibly it would be better to raise an error here

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

On Mon, Sep 9, 2013 at 9:52 AM, Nathaniel Smith wrote: > One list has 6 entries and one has 7, so they can't be aligned into a single > array. Possibly it would be better to raise an error here instead of > returning an object array, but that's what's going on. It did at some point (and I relied

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

Oh, so there was a bug in the user... On Mon, Sep 9, 2013 at 7:52 AM, Nathaniel Smith wrote: > One list has 6 entries and one has 7, so they can't be aligned into a > single array. Possibly it would be better to raise an error here instead of > returning an object array, but that's what's going

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

One list has 6 entries and one has 7, so they can't be aligned into a single array. Possibly it would be better to raise an error here instead of returning an object array, but that's what's going on. -n On 9 Sep 2013 14:49, "Chad Kidder" wrote: > I'm trying to enter a 2-D array and np.array() i

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] bug fixes: which branch?

On Sun, Jun 16, 2013 at 10:57 PM, Eric Firing wrote: > What is the preferred strategy for handling bug fix PRs? Initial fix on > master, and then a separate PR to backport to v1.7.x? Or the reverse? > It doesn't look like v1.7.x is being merged into master regularly, so > the matplotlib pattern

Re: [Numpy-discussion] bug in deepcopy() of rank-zero arrays?

hmm -- I suppose one of us should post an issue on github -- then ask for it ti be fixed before 1.8 ;-) I'll try to get to the issue if no one beats me to it -- got to run now... -Chris On Tue, Apr 30, 2013 at 5:35 AM, Richard Hattersley wrote: > +1 for getting rid of this inconsistency > >

Re: [Numpy-discussion] bug in deepcopy() of rank-zero arrays?

+1 for getting rid of this inconsistency We've hit this with Iris (a met/ocean analysis package - see github), and have had to add several workarounds. On 19 April 2013 16:55, Chris Barker - NOAA Federal wrote: > Hi folks, > > In [264]: np.__version__ > Out[264]: '1.7.0' > > I just noticed that

Re: [Numpy-discussion] Bug in np.records?

On Wed, Mar 20, 2013 at 2:57 PM, Pierre Barbier de Reuille < pierre.barbierdereui...@gmail.com> wrote: > Hey, > > I am trying to use titles for the record arrays. In the documentation, it > is specified that any column can set to "None". However, trying this fails > on numpy 1.6.2 because in np.co

Re: [Numpy-discussion] Bug with ufuncs made with frompyfunc

On Wed, Jan 9, 2013 at 7:23 AM, OKB (not okblacke) wrote: > A bug causing errors with using methods of ufuncs created with > frompyfunc was mentioned on the list over a year ago: > http://mail.scipy.org/pipermail/numpy-discussion/2011- > September/058501.html > > Is there any word

Re: [Numpy-discussion] Bug in as_strided/reshape

Sebastian Berg sipsolutions.net> writes: > > Hello, > > looking at the code, when only adding/removing dimensions with size 1, > numpy takes a small shortcut, however it uses 0 stride lengths as value > for the new one element dimensions temporarily, then replacing it again > to ensure the new

Re: [Numpy-discussion] Bug in as_strided/reshape

Hello, looking at the code, when only adding/removing dimensions with size 1, numpy takes a small shortcut, however it uses 0 stride lengths as value for the new one element dimensions temporarily, then replacing it again to ensure the new array is contiguous. This replacing does not check if the

Re: [Numpy-discussion] Bug in as_strided/reshape

Dave Hirschfeld gmail.com> writes: > > It seems that reshape doesn't work correctly on an array which has been > resized using the 0-stride trick e.g. > > In [73]: x = array([5]) > > In [74]: y = as_strided(x, shape=(10,), strides=(0,)) > > In [75]: y > Out[75]: array([5, 5, 5, 5, 5, 5, 5, 5,

Re: [Numpy-discussion] bug in numpy.where?

On 07/30/2012 10:53 AM, Travis Oliphant wrote: > Can you file a bug report on Github's issue tracker? It's https://github.com/numpy/numpy/issues/369 Phil ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo

Re: [Numpy-discussion] bug in numpy.where?

Can you file a bug report on Github's issue tracker? Thanks, -Travis On Jul 26, 2012, at 1:33 PM, Phil Hodge wrote: > On a Linux machine: > >> uname -srvop > Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 > GNU/Linux > > this example shows an apparent problem with the w

Re: [Numpy-discussion] bug in numpy.where?

On Mon, Jul 30, 2012 at 2:30 PM, Phil Hodge wrote: > On 07/27/2012 03:58 PM, Andreas Mueller wrote: >> Hi Everybody. >> The bug is that no error is raised, right? >> The docs say >> >> where(condition, [x, y]) >> >> x, y : array_like, optional >> Values from which to choose. `x` and `y` need

Re: [Numpy-discussion] bug in numpy.where?

On 07/27/2012 03:58 PM, Andreas Mueller wrote: > Hi Everybody. > The bug is that no error is raised, right? > The docs say > > where(condition, [x, y]) > > x, y : array_like, optional > Values from which to choose. `x` and `y` need to have the same > shape as `condition` > > In the exam

Re: [Numpy-discussion] bug in numpy.where?

On Fri, Jul 27, 2012 at 4:10 PM, Benjamin Root wrote: > > > On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller > wrote: > >> Hi Everybody. >> The bug is that no error is raised, right? >> The docs say >> >> where(condition, [x, y]) >> >> x, y : array_like, optional >> Values from which to cho

Re: [Numpy-discussion] bug in numpy.where?

On 07/27/2012 09:10 PM, Benjamin Root wrote: On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller mailto:amuel...@ais.uni-bonn.de>> wrote: Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Val

Re: [Numpy-discussion] bug in numpy.where?

On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller wrote: > Hi Everybody. > The bug is that no error is raised, right? > The docs say > > where(condition, [x, y]) > > x, y : array_like, optional > Values from which to choose. `x` and `y` need to have the same > shape as `condition` > > In

Re: [Numpy-discussion] bug in numpy.where?

Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy

Re: [Numpy-discussion] bug in numpy.where?

On Fri, Jul 27, 2012 at 2:01 PM, Benjamin Root wrote: > > > On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge wrote: > >> On a Linux machine: >> >> > uname -srvop >> Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 >> GNU/Linux >> >> this example shows an apparent problem with the

Re: [Numpy-discussion] bug in numpy.where?

On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge wrote: > On a Linux machine: > > > uname -srvop > Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 > GNU/Linux > > this example shows an apparent problem with the where function: > > Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43) >

Re: [Numpy-discussion] Bug in numpy.mean() revisited

On Fri, Jul 27, 2012 at 5:15 AM, Charles R Harris wrote: > I would support accumulating in 64 bits but, IIRC, the function will need to > be rewritten so that it works by adding 32 bit floats to the accumulator to > save space. There are also more stable methods that could also be > investigated.

Re: [Numpy-discussion] Bug in numpy.mean() revisited

On Thu, 2012-07-26 at 22:15 -0600, Charles R Harris wrote: > I would support accumulating in 64 bits but, IIRC, the function will > need to be rewritten so that it works by adding 32 bit floats to the > accumulator to save space. There are also more stable methods that > could also be investigated.

Re: [Numpy-discussion] Bug in numpy.mean() revisited

On Thu, Jul 26, 2012 at 9:26 PM, Tom Aldcroft wrote: > There was a thread in January discussing the non-obvious behavior of > numpy.mean() for large arrays of float32 values [1]. This issue is > nicely discussed at the end of the numpy.mean() documentation [2] with > an example: > > >>> a = np.z

Re: [Numpy-discussion] Bug in pickling an ndarray?

Thanks Travis and Robert for the clarification; it is much more clear what is going on now. As the demo code shows, also a.flags['OWNDATA'] is different on its way out of the pickle; which also makes sense now. So using that flag instead of checking a.base for None is equivalent, at least in this

Re: [Numpy-discussion] Bug in pickling an ndarray?

On Sat, Jun 30, 2012 at 11:33 PM, Daniel Hyams wrote: > Hmmm, I wouldn't think that it is correct behavior; I would think that *any* > ndarray arising from pickling would have its .base attribute set to None. >  If not, then who is really the one that owns the data? > > It was my understanding tha

Re: [Numpy-discussion] Bug in pickling an ndarray?

This is the expected behavior. It is not a bug. NumPy arrays after pickling are views into the String that is created by the pickling machinery. Thus, the base is set. This was done to avoid an additional memcpy. This avoids a copy, but yes, it does mean that you can't resize the array u

Re: [Numpy-discussion] Bug in pickling an ndarray?

Hmmm, I wouldn't think that it is correct behavior; I would think that *any* ndarray arising from pickling would have its .base attribute set to None. If not, then who is really the one that owns the data? It was my understanding that .base should hold a reference to another ndarray that the data

Re: [Numpy-discussion] Bug in pickling an ndarray?

On Sat, Jun 30, 2012 at 9:15 PM, Daniel Hyams wrote: > I am having trouble pickling (and then unpickling) an ndarray. Upon > unpickling, the "base" attribute of the ndarray is set to some very strange > string ("base" was None when the ndarray was pickled, so it should remain > None). This sounds

Re: [Numpy-discussion] bug in array instanciation?

On Fri, Jan 27, 2012 at 21:17, Emmanuel Mayssat wrote: > In [20]: dt_knobs = > [('pvName',(str,40)),('start','float'),('stop','float'),('mode',(str,10))] > > In [21]: r_knobs = np.recarray([],dtype=dt_knobs) > > In [22]: r_knobs > Out[22]: > rec.array(('\xa0\x8c\xc9\x02\x00\x00\x00\x00(\xc8v\x02\x

Re: [Numpy-discussion] bug in numpy.mean() ?

On Wed, Jan 25, 2012 at 12:03 AM, Charles R Harris wrote: > > > On Tue, Jan 24, 2012 at 4:21 PM, Kathleen M Tacina > wrote: >> >> I found something similar, with a very simple example. >> >> On 64-bit linux, python 2.7.2, numpy development version: >> >> In [22]: a = 4000*np.ones((1024,1024),dtyp

Re: [Numpy-discussion] bug in numpy.mean() ?

On Tue, Jan 24, 2012 at 4:21 PM, Kathleen M Tacina < kathleen.m.tac...@nasa.gov> wrote: > ** > I found something similar, with a very simple example. > > On 64-bit linux, python 2.7.2, numpy development version: > > In [22]: a = 4000*np.ones((1024,1024),dtype=np.float32) > > In [23]: a.mean() > Ou

Re: [Numpy-discussion] bug in numpy.mean() ?

On Tue, Jan 24, 2012 at 7:21 PM, eat wrote: > Hi > > On Wed, Jan 25, 2012 at 1:21 AM, Kathleen M Tacina < > kathleen.m.tac...@nasa.gov> wrote: > >> ** >> I found something similar, with a very simple example. >> >> On 64-bit linux, python 2.7.2, numpy development version: >> >> In [22]: a = 4000*

Re: [Numpy-discussion] bug in numpy.mean() ?

Hi On Wed, Jan 25, 2012 at 1:21 AM, Kathleen M Tacina < kathleen.m.tac...@nasa.gov> wrote: > ** > I found something similar, with a very simple example. > > On 64-bit linux, python 2.7.2, numpy development version: > > In [22]: a = 4000*np.ones((1024,1024),dtype=np.float32) > > In [23]: a.mean()

Re: [Numpy-discussion] bug in numpy.mean() ?

On Wed, Jan 25, 2012 at 01:12:06AM +0200, eat wrote: > Or does the results of calculations depend more on the platform? Floating point operations often do, sadly (not saying that this is the case here, but you'd need to try both versions on the same machine [or at least architecture/bit-width]/sa

Re: [Numpy-discussion] bug in numpy.mean() ?

I found something similar, with a very simple example. On 64-bit linux, python 2.7.2, numpy development version: In [22]: a = 4000*np.ones((1024,1024),dtype=np.float32) In [23]: a.mean() Out[23]: 4034.16357421875 In [24]: np.version.full_version Out[24]: '2.0.0.dev-55472ca' But, a Windows XP

Re: [Numpy-discussion] bug in numpy.mean() ?

Hi, Oddly, but numpy 1.6 seems to behave more consistent manner: In []: sys.version Out[]: '2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]' In []: np.version.version Out[]: '1.6.0' In []: d= np.load('data.npy') In []: d.dtype Out[]: dtype('float32') In []: d.mean() Out[]: 30

Re: [Numpy-discussion] bug in numpy.mean() ?

Thank you Bruce and all, I knew I was doing something wrong (should have read the mean method doc more closely). Am of course glad that's so easy understandable. But: If the error can get so big, wouldn't it be a better idea for the accumulator to always be of type 'float64' and then convert lat

Re: [Numpy-discussion] bug in numpy.mean() ?

> You have a million 32-bit floating point numbers that are in the > thousands. Thus you are exceeding the 32-bitfloat precision and, if you > can, you need to increase precision of the accumulator in np.mean() or > change the input dtype: a.mean(dtype=np.float32) # default and lacks precis

Re: [Numpy-discussion] bug in numpy.mean() ?

Just what Bruce said. You can run the following to confirm: np.mean(data - data.mean()) If for some reason you do not want to convert to float64 you can add the result of the previous line to the "bad" mean: bad_mean = data.mean() good_mean = bad_mean + np.mean(data - bad_mean) Val On Tue, Jan

Re: [Numpy-discussion] bug in numpy.mean() ?

On Jan 24, 2012, at 1:33 PM, K.-Michael Aye wrote: > I know I know, that's pretty outrageous to even suggest, but please > bear with me, I am stumped as you may be: > > 2-D data file here: > http://dl.dropbox.com/u/139035/data.npy > > Then: > In [3]: data.mean() > Out[3]: 3067.024383998 >

Re: [Numpy-discussion] bug in numpy.mean() ?

I have confirmed this on a 64-bit linux machine running python 2.7.2 with the development version of numpy. It seems to be related to using float32 instead of float64. If the array is first converted to a 64-bit float (via astype), mean gives an answer that agrees with your looped-calculation va

Re: [Numpy-discussion] bug in numpy.mean() ?

On 01/24/2012 12:33 PM, K.-Michael Aye wrote: > I know I know, that's pretty outrageous to even suggest, but please > bear with me, I am stumped as you may be: > > 2-D data file here: > http://dl.dropbox.com/u/139035/data.npy > > Then: > In [3]: data.mean() > Out[3]: 3067.024383998 > > In [4]:

Re: [Numpy-discussion] bug in PyArray_GetCastFunc

On Sun, Dec 4, 2011 at 6:30 PM, Geoffrey Irving wrote: > On Sun, Dec 4, 2011 at 10:02 AM, Charles R Harris > wrote: > > > > > > On Sat, Dec 3, 2011 at 5:28 PM, Geoffrey Irving wrote: > >> > >> When attempting to cast to a user defined type, PyArray_GetCast looks > >> up the cast function in the

Re: [Numpy-discussion] bug in PyArray_GetCastFunc

On Sun, Dec 4, 2011 at 10:02 AM, Charles R Harris wrote: > > > On Sat, Dec 3, 2011 at 5:28 PM, Geoffrey Irving wrote: >> >> When attempting to cast to a user defined type, PyArray_GetCast looks >> up the cast function in the dictionary but doesn't check if the entry >> exists.  This causes segfau

Re: [Numpy-discussion] bug in PyArray_GetCastFunc

On Sat, Dec 3, 2011 at 5:28 PM, Geoffrey Irving wrote: > When attempting to cast to a user defined type, PyArray_GetCast looks > up the cast function in the dictionary but doesn't check if the entry > exists. This causes segfaults. Here's a patch. > > Geoffrey > > diff --git a/numpy/core/src/mu

Re: [Numpy-discussion] bug in reshape ?

2011/11/23 : > might be an old story >>> np.__version__  -> '1.5.1' I have only a numpy 1.4.1 for testing atm, but I believe this corner case never occured and hence never got fixed since then. Confirming your issue on that. > It thought for once it's easier to use reshape to add a new axis > i

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 22:11, Bruce Southey wrote: > On Sat, Sep 17, 2011 at 10:00 PM, Wes McKinney wrote: >> On Sat, Sep 17, 2011 at 10:50 PM, Bruce Southey wrote: >>> On Sat, Sep 17, 2011 at 4:12 PM, Wes McKinney wrote: On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote:

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 10:00 PM, Wes McKinney wrote: > On Sat, Sep 17, 2011 at 10:50 PM, Bruce Southey wrote: >> On Sat, Sep 17, 2011 at 4:12 PM, Wes McKinney wrote: >>> On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold >>> wrote: Just ran into this. Any objections for having numpy.std an

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 10:50 PM, Bruce Southey wrote: > On Sat, Sep 17, 2011 at 4:12 PM, Wes McKinney wrote: >> On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote: >>> Just ran into this. Any objections for having numpy.std and other >>> functions in core/fromnumeric.py call asanyarray befo

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 21:50, Bruce Southey wrote: > numpy.std()  does accepts array-like which obvious means that > np.std([1,2,3,5]) works making asanyarray call a total waste of cpu > time. Clearly pandas is not array-like input (as Wes points out below) > so an error is correct. No. Even li

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 4:12 PM, Wes McKinney wrote: > On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote: >> Just ran into this. Any objections for having numpy.std and other >> functions in core/fromnumeric.py call asanyarray before trying to use >> the array's method? Other data structures

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 8:36 PM, wrote: > On Sat, Sep 17, 2011 at 5:12 PM, Wes McKinney wrote: >> On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote: >>> Just ran into this. Any objections for having numpy.std and other >>> functions in core/fromnumeric.py call asanyarray before trying to u

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 5:12 PM, Wes McKinney wrote: > On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote: >> Just ran into this. Any objections for having numpy.std and other >> functions in core/fromnumeric.py call asanyarray before trying to use >> the array's method? Other data structures

Re: [Numpy-discussion] Bug in numpy std, etc. with other data structures?

On Sat, Sep 17, 2011 at 4:48 PM, Skipper Seabold wrote: > Just ran into this. Any objections for having numpy.std and other > functions in core/fromnumeric.py call asanyarray before trying to use > the array's method? Other data structures like pandas and larry define > their own std method, for i

Re: [Numpy-discussion] Bug or feature?

On Tue, Aug 23, 2011 at 1:13 PM, Fernando Perez wrote: > Off the top of my head, here are a few ideas for enterprising souls to make a > very useful contribution with a howto on each of these topics: > > - dtype/structured arrays and record arrays > - fancy indexing, broadcasting, lib.index_trick

Re: [Numpy-discussion] Bug or feature?

On Mon, Aug 22, 2011 at 11:28 PM, Konrad Hinsen wrote: > Thanks, that sounds reasonable. But is this role of tuples in the > creation of structured arrays documented anywhere? The documentation > on structured arrays concentrates on specifying the dtype. All I could > find about array constructio

Re: [Numpy-discussion] Bug or feature?

On 22 Aug 2011, at 14:50, Travis Oliphant wrote: > This goes into the category of "feature". Structured arrays use > tuples to indicate a record. So, (only) when using structured > arrays as a dtype, there is a difference between lists and > tuples.In this case, array sees the tuple a

Re: [Numpy-discussion] Bug or feature?

This goes into the category of "feature". Structured arrays use tuples to indicate a record. So, (only) when using structured arrays as a dtype, there is a difference between lists and tuples.In this case, array sees the tuple and expects it to have 2 elements to match the number of field

Re: [Numpy-discussion] bug with assignment into an indexed array?

On Wed, Aug 17, 2011 at 11:54 AM, Benjamin Root wrote: > On Sat, Aug 13, 2011 at 7:17 PM, Mark Wiebe wrote: > >> On Thu, Aug 11, 2011 at 1:37 PM, Benjamin Root wrote: >> >>> On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote: >>> 2011/8/11 Benjamin Root > > > On Th

Re: [Numpy-discussion] bug with assignment into an indexed array?

On Sat, Aug 13, 2011 at 7:17 PM, Mark Wiebe wrote: > On Thu, Aug 11, 2011 at 1:37 PM, Benjamin Root wrote: > >> On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote: >> >>> 2011/8/11 Benjamin Root >>> On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote: > Maybe

Re: [Numpy-discussion] bug with assignment into an indexed array?

On Thu, Aug 11, 2011 at 1:37 PM, Benjamin Root wrote: > On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote: > >> 2011/8/11 Benjamin Root >> >>> >>> >>> On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote: >>> Maybe confusing, but working as expected. When you wri

Re: [Numpy-discussion] bug with latest numpy git snapshot build with Python3

On 13. aug. 2011, at 20.42, Charles R Harris wrote: > > > 2011/8/11 Dmitrey > bug in KUBUNTU 11.04, latest numpy git snapshot build with Python3 > >>> import numpy > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python3.2/dist-packages/numpy/__init__.py",

Re: [Numpy-discussion] bug with latest numpy git snapshot build with Python3

2011/8/11 Dmitrey > bug in KUBUNTU 11.04, latest numpy git snapshot build with Python3 > >>> import numpy > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python3.2/dist-packages/numpy/__init__.py", line > 137, in > from . import add_newdocs > File "/

Re: [Numpy-discussion] bug with assignment into an indexed array?

On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote: > 2011/8/11 Benjamin Root > >> >> >> On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote: >> >>> Maybe confusing, but working as expected. >>> >>> >>> When you write: >>> matched_to[np.array([0, 1, 2])] = 3 >>> it calls __setitem

Re: [Numpy-discussion] bug with assignment into an indexed array?

2011/8/11 Benjamin Root > > > On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote: > >> Maybe confusing, but working as expected. >> >> >> When you write: >> matched_to[np.array([0, 1, 2])] = 3 >> it calls __setitem__ on matched_to, with arguments (np.array([0, 1, 2]), >> 3). So numpy und

Re: [Numpy-discussion] bug with assignment into an indexed array?

On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote: > Maybe confusing, but working as expected. > > > When you write: > matched_to[np.array([0, 1, 2])] = 3 > it calls __setitem__ on matched_to, with arguments (np.array([0, 1, 2]), > 3). So numpy understand you want to write 3 at these ind

  1   2   3   4   >