Re: [Numpy-discussion] Release blockers for 1.4.0 ?

2009/12/8 Robert Kern : > On Tue, Dec 8, 2009 at 15:25, Pierre GM wrote: >> On Dec 8, 2009, at 12:54 PM, Robert Kern wrote: >>> >>> As far as I can tell, the faulty global seterr() has been in place >>> since 1.1.0, so fixing it at all should be considered a feature >>> change. It's not likely to

Re: [Numpy-discussion] Assigning complex values to a real array

Darren Dale wrote: > > On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern wrote: > >> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt >> wrote: >> > 2009/3/7 Robert Kern : >> >> In [5]: z = zeros(3, int) >> >> >> >> In [6]: z[1] = 1.5 >> >> >> >> In [7]: z >> >> Out[7]: array([0, 1, 0]) >> > >> >

Re: [Numpy-discussion] Assigning complex values to a real array

Stéfan van der Walt wrote: > > > Would it be possible to, optionally, throw an exception? > > S. > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > I'm certain that it i

Re: [Numpy-discussion] Flattening an array

On Tue, Dec 8, 2009 at 7:29 PM, Jake VanderPlas wrote: > Hello, > I have a function -- call it f() -- which takes a length-N 1D numpy > array as an argument, and returns a length-N 1D array. > I want to pass it the data in an N-D array, and obtain the N-D array > of the result. > I've thought abou

Re: [Numpy-discussion] slices of structured arrays?

2009/12/8 Ernest Adrogué : > Hello, > > Here's a structured array with fields 'a','b' and 'c': > > s=[(i,int) for i in 'abc'] > t=np.zeros(1,s) > > It has the form: array([(0, 0, 0)] > > I was wondering if such an array can be accessed like an > ordinary array (e.g., with a slice) in order to set m

Re: [Numpy-discussion] Assigning complex values to a real array

On 12/08/09 02:32, David Warde-Farley wrote: > On 7-Dec-09, at 11:13 PM, Dr. Phillip M. Feldman wrote: > > > Example #1: > > IPython 0.10 [on Py 2.5.4] > > [~]|1> z= zeros(3) > > [~]|2> z[0]= 1+1J > > > > TypeError: can't convert complex to float; use abs(z) > > The problem is that you're using

Re: [Numpy-discussion] Assigning complex values to a real array

On Tue, Dec 08, 2009 at 10:17:20AM -0800, Dr. Phillip M. Feldman wrote: > > > > David Warde-Farley-2 wrote: > > > > > > A less harmful solution (if a solution is warranted, which is for the > > Council of the Elders to > > decide) would be to treat the Python complex type as a special case,

Re: [Numpy-discussion] more recfunctions, structured array help

Pierre GM-2 wrote: > > On Dec 8, 2009, at 7:27 PM, John [H2O] wrote: >> Maybe I should add, I'm looking at this thread: >> http://old.nabble.com/masked-record-arrays-td26237612.html >> >> And, I guess I'm in the same situation as the OP there. It's not clear to >> me, but as best I can tell I

Re: [Numpy-discussion] more recfunctions, structured array help

On Dec 8, 2009, at 7:11 PM, John [H2O] wrote: > My apologies for adding confusing. In answer to your first question. Yes at > one point I tried playing with scikits.timeseries... there were some issues > at the time that prevented me from working with it, maybe I should revisit. What kind of issue

Re: [Numpy-discussion] more recfunctions, structured array help

On Dec 8, 2009, at 7:27 PM, John [H2O] wrote: > Maybe I should add, I'm looking at this thread: > http://old.nabble.com/masked-record-arrays-td26237612.html > > And, I guess I'm in the same situation as the OP there. It's not clear to > me, but as best I can tell I am working with structured array

[Numpy-discussion] slices of structured arrays?

Hello, Here's a structured array with fields 'a','b' and 'c': s=[(i,int) for i in 'abc'] t=np.zeros(1,s) It has the form: array([(0, 0, 0)] I was wondering if such an array can be accessed like an ordinary array (e.g., with a slice) in order to set multiple values at once. t[0] does not access

Re: [Numpy-discussion] Can't set an element of a subset of an array, , ,

>2009/12/8 : >> Okay, I'm stuck. Why doesn't this work? >> >> In [226]: mask >> Out[226]: array([False, False, False, ..., False, False, False], dtype=bool) >> In [229]: mask[data['horizon']==i][2] = True > >mask[data['horizon']==i] creates a copy. mask[data['horizon']==i][2] >assigns to the copy,

Re: [Numpy-discussion] Can't set an element of a subset of an array, , ,

2009/12/8 : > Okay, I'm stuck. Why doesn't this work? > > In [226]: mask > Out[226]: array([False, False, False, ..., False, False, False], dtype=bool) > In [229]: mask[data['horizon']==i][2] = True mask[data['horizon']==i] creates a copy. mask[data['horizon']==i][2] assigns to the copy, which th

[Numpy-discussion] Can't set an element of a subset of an array, , ,

Okay, I'm stuck. Why doesn't this work? In [226]: mask Out[226]: array([False, False, False, ..., False, False, False], dtype=bool) In [227]: mask[data['horizon']==i] Out[227]: array([ True, True, False, False, True, False, False, False, False, True, False, False, False, True, False, F

[Numpy-discussion] Flattening an array

Hello, I have a function -- call it f() -- which takes a length-N 1D numpy array as an argument, and returns a length-N 1D array. I want to pass it the data in an N-D array, and obtain the N-D array of the result. I've thought about wrapping it as such: #python code: from my_module import f # ta

Re: [Numpy-discussion] more recfunctions, structured array help

Maybe I should add, I'm looking at this thread: http://old.nabble.com/masked-record-arrays-td26237612.html And, I guess I'm in the same situation as the OP there. It's not clear to me, but as best I can tell I am working with structured arrays (that's from np.rec.fromrecords creates, no?). Anywa

Re: [Numpy-discussion] more recfunctions, structured array help

Pierre GM-2 wrote: > > > Did you check scikits.timeseries ? Might be a solution if you have data > indexed in time > > >> np.rec.fromrecords(codata_masked,names='datetime,lon,lat,elv,co') >>return codata, codata_masked > > OK, I gonna have to guess again: > codata is a regular ndarray, n

Re: [Numpy-discussion] What protocol to use now?

Robert Kern wrote: > On Tue, Dec 8, 2009 at 17:41, Christopher Barker > wrote: >> My suggested new wording: >> >> """ >> Warning >> >> This page describes the current array interface. Everything still works >> as described as of numpy 1.4 and on into the foreseeable future. >> However, future ver

Re: [Numpy-discussion] What protocol to use now?

On Tue, Dec 8, 2009 at 17:41, Christopher Barker wrote: > Pauli Virtanen wrote: >>> I think the wording is overly strong. > > not just too string, but actually wrong -- you can't target PEP 3118 -- > numpy doesn't support it at all yet! > > > Current wording: > > """ > Warning > > This page descri

Re: [Numpy-discussion] numpy distutils breaks scipy install on mac

On Wed, Dec 9, 2009 at 6:47 AM, Robert Kern wrote: > > Right. The -arch flag was added by Apple to GCC and their patch really > should be applied to all builds of GCC compilers for the Mac. It is > deeply disappointing that Fink ignored this. The only Mac gfortran > build that I can recommend is h

Re: [Numpy-discussion] What protocol to use now?

Pauli Virtanen wrote: >> I think the wording is overly strong. not just too string, but actually wrong -- you can't target PEP 3118 -- numpy doesn't support it at all yet! Current wording: """ Warning This page describes the old, deprecated array interface. Everything still works as describe

Re: [Numpy-discussion] more recfunctions, structured array help

On Dec 8, 2009, at 5:32 PM, John [H2O] wrote: > Pierre GM-2 wrote: >> >> >> >> masked_where is a function that requires 2 arguments. >> If you try to mask a whole record, you can try something like > x = ma.array([('a',1),('b',2)],dtype=[('','|S1'),('',float)]) > x[x['f0']=='a'] = ma.mas

Re: [Numpy-discussion] more recfunctions, structured array help

Pierre GM-2 wrote: > > > > masked_where is a function that requires 2 arguments. > If you try to mask a whole record, you can try something like x = ma.array([('a',1),('b',2)],dtype=[('','|S1'),('',float)]) x[x['f0']=='a'] = ma.masked > For an individual field, try something like >>>

Re: [Numpy-discussion] What protocol to use now?

ti, 2009-12-08 kello 14:23 -0600, Robert Kern kirjoitti: [clip] > I think the wording is overly strong. I don't think that we actually > decided to deprecate the interface. PEP 3118 is not yet implemented by > numpy, and the PEP 3118 API won't be available to Python's <2.6 > (Cython's workarounds n

Re: [Numpy-discussion] more recfunctions, structured array help

On Dec 8, 2009, at 4:53 PM, John [H2O] wrote: > This is what I get: > > In [74]: type(cd) > Out[74]: > > In [75]: type(cd.co) > Out[75]: > > In [76]: cd[cd['co']==-.] = np.ma.masked > --- > ValueError

Re: [Numpy-discussion] more recfunctions, structured array help

This is what I get: In [74]: type(cd) Out[74]: In [75]: type(cd.co) Out[75]: In [76]: cd[cd['co']==-.] = np.ma.masked --- ValueErrorTraceback (most recent call last) /home/jfb/Research

Re: [Numpy-discussion] What protocol to use now?

On Tue, Dec 8, 2009 at 15:44, Christopher Barker wrote: > Robert Kern wrote: >>> The array interface was made for this sort of thing, but is deprecated: >>> >>> http://docs.scipy.org/doc/numpy/reference/arrays.interface.html > >> I think the wording is overly strong. I don't think that we actually

Re: [Numpy-discussion] numpy distutils breaks scipy install on mac

On Tue, Dec 8, 2009 at 15:36, Mark Sienkiewicz wrote: > When I compile scipy on a mac, the build fails with: > > ... > gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f > f951: error: unrecognized command line option "-arch" > f951: error: unrecognized command line option "-arch" > f951: error: un

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Dec 8, 2009, at 4:36 PM, Robert Kern wrote: >> >>err_status_ini = np.geterr() >>np.seterr(divide='ignore', invalid='ignore') >>result = self.f(da, db, *args, **kwargs) >>np.seterr(**err_status_ini) >> >> Is this kind of fix acceptable ? > > olderr = np.seterr(

Re: [Numpy-discussion] What protocol to use now?

Robert Kern wrote: >> The array interface was made for this sort of thing, but is deprecated: >> >> http://docs.scipy.org/doc/numpy/reference/arrays.interface.html > I think the wording is overly strong. I don't think that we actually > decided to deprecate the interface. PEP 3118 is not yet imple

Re: [Numpy-discussion] more recfunctions, structured array help

On Dec 8, 2009, at 3:42 PM, John [H2O] wrote: > I see record arrays don't have a masked_where method. How can I achieve the > following for a record array: > > cd.masked_where(cd.co == -.) > > Or something like this. masked_where is a function that requires 2 arguments. If you try to mask a

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Tue, Dec 8, 2009 at 15:25, Pierre GM wrote: > On Dec 8, 2009, at 12:54 PM, Robert Kern wrote: >> >> As far as I can tell, the faulty global seterr() has been in place >> since 1.1.0, so fixing it at all should be considered a feature >> change. It's not likely to actually *break* things except

[Numpy-discussion] numpy distutils breaks scipy install on mac

When I compile scipy on a mac, the build fails with: ... gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f f951: error: unrecognized command line option "-arch" f951: error: unrecognized command line option "-arch" f951: error: unrecognized command line option "-arch" f951: error: unrecognized com

Re: [Numpy-discussion] Cython issues w/ 1.4.0

ti, 2009-12-08 kello 21:52 +0100, Dag Sverre Seljebotn kirjoitti: [clip] > How about this: > - Cache/store the format string in a bytes object in a global > WeakRefKeyDict (?), keyed by dtype > - The array holds a ref to the dtype, and the Py_buffer holds a ref to > the array (through the ob

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Dec 8, 2009, at 12:54 PM, Robert Kern wrote: > > As far as I can tell, the faulty global seterr() has been in place > since 1.1.0, so fixing it at all should be considered a feature > change. It's not likely to actually *break* things except for doctests > and documentation. I think I fall in w

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Tue, Dec 8, 2009 at 14:52, Dag Sverre Seljebotn wrote: > Robert Kern wrote: >> On Tue, Dec 8, 2009 at 12:38, Pauli Virtanen wrote: >>> - We need to cache the buffer protocol format string somewhere, >>>  if we do not want to regenerate it on each buffer acquisition. >> >> My suspicion is that

[Numpy-discussion] doctest improvements patch (and possible regressions)

Hi Numpy-devs, I'm a long time listener, first time caller. I grabbed 1.4.0rc1 and was happy that all the tests passed. But then I tried: >>> import numpy as np >>> np.test(doctests=True) ... Ran 1696 tests in 22.027s FAILED (failures=113, errors=24) I looked at some of the failu

Re: [Numpy-discussion] Cython issues w/ 1.4.0

Robert Kern wrote: > On Tue, Dec 8, 2009 at 12:38, Pauli Virtanen wrote: >> ti, 2009-12-08 kello 12:14 -0600, Robert Kern kirjoitti: >>> On Tue, Dec 8, 2009 at 12:08, Pauli Virtanen wrote: ke, 2009-12-09 kello 02:47 +0900, David Cournapeau kirjoitti: [clip] > Of course, this does no

[Numpy-discussion] more recfunctions, structured array help

I see record arrays don't have a masked_where method. How can I achieve the following for a record array: cd.masked_where(cd.co == -.) Or something like this. Thanks! -- View this message in context: http://old.nabble.com/more-recfunctions%2C-structured-array-help-tp26700380p26700380.htm

Re: [Numpy-discussion] What protocol to use now?

On Tue, Dec 8, 2009 at 12:34, Christopher Barker wrote: > Hi folks, > > There was just a question on the wxPython list about how to optimize > some drawing of data in numpy arrays. Currently, wxPython uses > PySequenceGetItem to iterate through an array, so you can imagine there > is a fair bit of

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Tue, Dec 8, 2009 at 12:38, Pauli Virtanen wrote: > ti, 2009-12-08 kello 12:14 -0600, Robert Kern kirjoitti: >> On Tue, Dec 8, 2009 at 12:08, Pauli Virtanen wrote: >> > ke, 2009-12-09 kello 02:47 +0900, David Cournapeau kirjoitti: >> > [clip] >> >> Of course, this does not prevent from applying

Re: [Numpy-discussion] Cython issues w/ 1.4.0

ti, 2009-12-08 kello 12:14 -0600, Robert Kern kirjoitti: > On Tue, Dec 8, 2009 at 12:08, Pauli Virtanen wrote: > > ke, 2009-12-09 kello 02:47 +0900, David Cournapeau kirjoitti: > > [clip] > >> Of course, this does not prevent from applying your suggested change - > >> I don't understand why you wa

[Numpy-discussion] What protocol to use now?

Hi folks, There was just a question on the wxPython list about how to optimize some drawing of data in numpy arrays. Currently, wxPython uses PySequenceGetItem to iterate through an array, so you can imagine there is a fair bit of overhead in that. But what to use? We don't want to require nu

Re: [Numpy-discussion] Assigning complex values to a real array

David Warde-Farley-2 wrote: > > > A less harmful solution (if a solution is warranted, which is for the > Council of the Elders to > decide) would be to treat the Python complex type as a special case, so > that the .real attribute is accessed instead of trying to cast to float. > > There

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Tue, Dec 8, 2009 at 12:08, Pauli Virtanen wrote: > ke, 2009-12-09 kello 02:47 +0900, David Cournapeau kirjoitti: > [clip] >> Of course, this does not prevent from applying your suggested change - >> I don't understand why you want to add it to 1.4.0, though. 1.4.0 does >> not break the ABI comp

Re: [Numpy-discussion] Cython issues w/ 1.4.0

ke, 2009-12-09 kello 02:47 +0900, David Cournapeau kirjoitti: [clip] > Of course, this does not prevent from applying your suggested change - > I don't understand why you want to add it to 1.4.0, though. 1.4.0 does > not break the ABI compared to 1.3.0. Or is it "just" to avoid the > cython issue t

[Numpy-discussion] Complex zerodivision/negative powers not handled correctly

Hi, I have observed a problem with complex zerodivision and negative powers. With a complex zero the result is either zero or NaN NaNj, the first one is clearly wrong and the other one I don't know what is most reasonable some kind of inf or a Nan. This problem has been reported in the tracker

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Tue, Dec 8, 2009 at 11:41, David Cournapeau wrote: > On Wed, Dec 9, 2009 at 1:21 AM, Robert Kern wrote: > >> The default has always been "print", not "warn" (except for underflow, >> which was "ignore"). > > Ah, ok, that explains part of the misunderstanding, sorry for the confusion. > >> Howe

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Wed, Dec 9, 2009 at 2:37 AM, Pauli Virtanen wrote: > ke, 2009-12-09 kello 02:28 +0900, David Cournapeau kirjoitti: > [clip] >> It seems that it is partly a cython problem. If py3k can be done for >> numpy 1.5, I wonder if we should focus on making incompatible numpy >> 1.6 (or 2.0 :) ), with an

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Wed, Dec 9, 2009 at 1:21 AM, Robert Kern wrote: > The default has always been "print", not "warn" (except for underflow, > which was "ignore"). Ah, ok, that explains part of the misunderstanding, sorry for the confusion. > However, "warn" is better for the reasons you > state (except for und

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Tue, Dec 8, 2009 at 11:28, David Cournapeau wrote: > On Wed, Dec 9, 2009 at 2:02 AM, Pauli Virtanen wrote: >> Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote: >>> I have a lot of code that has stopped working with my latest SVN pull to >>> numpy. >>> >>> * Some compiled code yields an er

Re: [Numpy-discussion] Cython issues w/ 1.4.0

ke, 2009-12-09 kello 02:28 +0900, David Cournapeau kirjoitti: [clip] > It seems that it is partly a cython problem. If py3k can be done for > numpy 1.5, I wonder if we should focus on making incompatible numpy > 1.6 (or 2.0 :) ), with an emphasis on making the C api more robust > about those change

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Wed, Dec 09, 2009 at 02:28:46AM +0900, David Cournapeau wrote: > As numpy becomes more and more used as a basic for so many softwares, > I feel like the current situation is hurting numpy users quite badly. > Maybe I am overestimate the problem, though ? I think you are right. It is going to hu

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Wed, Dec 9, 2009 at 2:02 AM, Pauli Virtanen wrote: > Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote: >> I have a lot of code that has stopped working with my latest SVN pull to >> numpy. >> >> * Some compiled code yields an error looking like (from memory): >> >>     "incorrect type 'num

Re: [Numpy-discussion] Cython issues w/ 1.4.0

ti, 2009-12-08 kello 12:12 -0500, Darren Dale kirjoitti: > On Tue, Dec 8, 2009 at 12:02 PM, Pauli Virtanen wrote: > > Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote: > >> I have a lot of code that has stopped working with my latest SVN pull to > >> numpy. > >> > >> * Some compiled code yiel

Re: [Numpy-discussion] Cython issues w/ 1.4.0

On Tue, Dec 8, 2009 at 12:02 PM, Pauli Virtanen wrote: > Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote: >> I have a lot of code that has stopped working with my latest SVN pull to >> numpy. >> >> * Some compiled code yields an error looking like (from memory): >> >>     "incorrect type 'nu

[Numpy-discussion] Cython issues w/ 1.4.0

Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote: > I have a lot of code that has stopped working with my latest SVN pull to > numpy. > > * Some compiled code yields an error looking like (from memory): > > "incorrect type 'numpy.ndarray'" This, by the way, also affects the 1.4.x branch

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Tue, Dec 8, 2009 at 10:12, David Cournapeau wrote: > On Wed, Dec 9, 2009 at 12:57 AM, Pauli Virtanen wrote: > >> >> Also, some code that worked OK before would now start to spit out extra >> warnings, which is not so nice. > > Hm, there are several things mixed up in this discussion, I feel li

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Wed, Dec 9, 2009 at 12:57 AM, Pauli Virtanen wrote: > > Also, some code that worked OK before would now start to spit out extra > warnings, which is not so nice. Hm, there are several things mixed up in this discussion, I feel like we are not talking about exactly the same thing: - I am talk

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

ke, 2009-12-09 kello 00:21 +0900, David Cournapeau kirjoitti: > On Wed, Dec 9, 2009 at 12:10 AM, Bruce Southey wrote: > > > > > I understand the reason for the masked arrays behavior but changing the > > seterr default will be a problem until ma is changed. With Python 2.6 and > > numpy '1.4.0.de

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Tue, Dec 8, 2009 at 10:21 AM, David Cournapeau wrote: > On Wed, Dec 9, 2009 at 12:10 AM, Bruce Southey wrote: > >> >> I understand the reason for the masked arrays behavior but changing the >> seterr default will be a problem until ma is changed. With Python 2.6 and >> numpy '1.4.0.dev7750', t

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Wed, Dec 9, 2009 at 12:10 AM, Bruce Southey wrote: > > I understand the reason for the masked arrays behavior but changing the > seterr default will be a problem until ma is changed. With Python 2.6 and > numpy '1.4.0.dev7750', the current default works but fails when changing the > seterr def

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On 12/08/2009 08:36 AM, Charles R Harris wrote: On Tue, Dec 8, 2009 at 12:31 AM, David Cournapeau mailto:da...@ar.media.kyoto-u.ac.jp>> wrote: Pierre GM wrote: > A bit of background first; > In the first implementations of numpy.core.ma , the approach w

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Tue, Dec 8, 2009 at 12:31 AM, David Cournapeau < da...@ar.media.kyoto-u.ac.jp> wrote: > Pierre GM wrote: > > A bit of background first; > > In the first implementations of numpy.core.ma, the approach was to get > rid of the data that could cause problem beforehand by replacing them with > safe

Re: [Numpy-discussion] Assigning complex values to a real array

>> At a minimum, this inconsistency needs to be cleared up.  My >> preference >> would be that the programmer should have to explicitly downcast from >> complex to float, and that if he/she fails to do this, that an >> exception be >> triggered. > > That would most likely break a *lot* of deployed

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

Pierre GM wrote: > > Will try. We're still supporting 2.3, right ? > We stopped supporting 2.3 starting at 1.3 I think. We require 2.4, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo

Re: [Numpy-discussion] Py3 merge

On Tue, Dec 8, 2009 at 8:03 PM, Francesc Alted wrote: > > That's true, but at least this can be attributed to a poor programming > practice.  The same happens with: > > array([1]).dtype == 'int32'  # in 32-bit systems > array([1]).dtype == 'int64'  # in 64-bit systems > > and my impression is tha

Re: [Numpy-discussion] Py3 merge

A Monday 07 December 2009 16:32:50 Pauli Virtanen escrigué: > ma, 2009-12-07 kello 09:50 -0500, Michael Droettboom kirjoitti: > > Pauli Virtanen wrote: > > [clip] > > > > The character 'B' is already by unsigned bytes -- I wonder if it's easy > > > to support 'B123' and plain 'B' at the same time

Re: [Numpy-discussion] Zero Division not handled correctly?

Thanks, Dave! DG On Tue, Dec 8, 2009 at 12:04 AM, David Cournapeau wrote: > On Mon, Dec 7, 2009 at 6:16 AM, Skipper Seabold > wrote: > > I believe this is known, but I am surprised that division by "integer" > > zero results in the following. > > > > In [1]: import numpy as np > > > > In [2]: n

Re: [Numpy-discussion] Release blockers for 1.4.0 ?

On Dec 8, 2009, at 2:31 AM, David Cournapeau wrote: > Pierre GM wrote: >> A bit of background first; >> In the first implementations of numpy.core.ma, the approach was to get rid >> of the data that could cause problem beforehand by replacing them with safe >> values. Turned out that finding thes

Re: [Numpy-discussion] Build error

On Tue, Dec 08, 2009 at 09:25:22AM +0100, Gael Varoquaux wrote: > I just did an SVN up, and I am getting a build error: Please ignore this. Brain fart. I should refrain from doing anything before coffee. Gaël ___ NumPy-Discussion mailing list NumPy-Disc

[Numpy-discussion] Build error

I just did an SVN up, and I am getting a build error: $ python setup.py build_ext --inplace ... building extension "numpy.linalg.lapack_lite" sources adding 'numpy/linalg/lapack_litemodule.c' to sources. adding 'numpy/linalg/python_xerbla.c' to sources. building extension "numpy.random.mtrand"

Re: [Numpy-discussion] Zero Division not handled correctly?

On Mon, Dec 7, 2009 at 6:16 AM, Skipper Seabold wrote: > I believe this is known, but I am surprised that division by "integer" > zero results in the following. > > In [1]: import numpy as np > > In [2]: np.__version__ > Out[2]: '1.4.0.dev7539' > > In [3]: 0**-1 # or 0**-1/-1 > ---