Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On 4/5/2011 7:44 PM, Mark Wiebe wrote: > On Tue, Apr 5, 2011 at 7:21 PM, Christoph Gohlke > wrote: > > > > On 4/5/2011 6:46 PM, Mark Wiebe wrote: > > On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke > >

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 7:21 PM, Christoph Gohlke wrote: > > > On 4/5/2011 6:46 PM, Mark Wiebe wrote: > > On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke > > wrote: > > > > > > > > On 4/5/2011 4:05 PM, Mark Wiebe wrote: > > > On Mon, Apr 4, 2011 at 9:10 PM, Chris

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On 4/5/2011 6:46 PM, Mark Wiebe wrote: > On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke > wrote: > > > > On 4/5/2011 4:05 PM, Mark Wiebe wrote: > > On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke > >

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke wrote: > > > On 4/5/2011 4:05 PM, Mark Wiebe wrote: > > On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke > > wrote: > > > > > > > > > > A few numpy tests fail on win-amd64: > > > > > > > > > ==

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke wrote: > > > On 4/5/2011 4:05 PM, Mark Wiebe wrote: > > On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke > > wrote: > > > > > > > > > > A few numpy tests fail on win-amd64: > > > > > > > > > ==

Re: [Numpy-discussion] Remove deprecated skiprows

On Tue, Apr 5, 2011 at 7:32 PM, Robert Kern wrote: > On Tue, Apr 5, 2011 at 18:20, Wes McKinney wrote: > >> FYI: >> >> http://docs.python.org/library/warnings.html >> >> "DeprecationWarning     Base category for warnings about deprecated >> features (ignored by default)." >> >> Maybe DeprecationW

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On 4/5/2011 4:05 PM, Mark Wiebe wrote: > On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke > wrote: > > > > > A few numpy tests fail on win-amd64: > > > > == > FAIL: test_iterator.tes

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

Hi, On Tue, Apr 5, 2011 at 4:12 PM, Christopher Barker wrote: > On 4/5/11 3:36 PM, josef.p...@gmail.com wrote: >>> I disagree that U makes no sense for binary file reading. > > I wasn't saying that it made no sense to have a "U" mode for binary file > reading, what I meant is that by the python2

Re: [Numpy-discussion] Remove deprecated skiprows

On Tue, Apr 5, 2011 at 18:20, Wes McKinney wrote: > FYI: > > http://docs.python.org/library/warnings.html > > "DeprecationWarning     Base category for warnings about deprecated > features (ignored by default)." > > Maybe DeprecationWarnings should be changed to something that isn't > ignored by

Re: [Numpy-discussion] Remove deprecated skiprows

On Tue, Apr 5, 2011 at 5:52 PM, Ralf Gommers wrote: > On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold wrote: >> On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris >> wrote: >>> Should skiprows be removed? >>> >>>     if skiprows: >>>     warnings.warn(\ >>>     "The use of `skiprows`

[Numpy-discussion] atpy and readable buffer error

I get this error that I do not understand. Does anyone know what is happening and how to get around it >>> import atpy >>> t = atpy.Table() >>> name = ["aa","bb","cc"] >>> t.add_column("name",name) >>> k = [1,2,3] >>> t.add_column("num",k) >>> t >>> name = ["aaa","bbb","ccc"] >>> p = atpy.Table()

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On 4/5/11 3:36 PM, josef.p...@gmail.com wrote: >> I disagree that U makes no sense for binary file reading. I wasn't saying that it made no sense to have a "U" mode for binary file reading, what I meant is that by the python2 definition, it made no sense. In Python 2, the ONLY difference between

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke wrote: > > > > A few numpy tests fail on win-amd64: > > > > == > FAIL: test_iterator.test_iter_broadcasting_errors > -

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 5:56 PM, Matthew Brett wrote: > Hi, > > On Tue, Apr 5, 2011 at 9:46 AM, Christopher Barker > wrote: >> On 4/4/11 10:35 PM, Charles R Harris wrote: >>>     IIUC, "Ub" is undefined -- "U" means universal newlines, which makes no >>>     sense when used with "b" for binary. I

Re: [Numpy-discussion] Remove deprecated skiprows

On Apr 6, 2011, at 12:16 AM, Alan G Isaac wrote: > On 4/5/2011 6:11 PM, Skipper Seabold wrote: >> To my mind, skip_headers is a bool Well, that's understandable... So, yet another change of name to skip_header_lines, skip_footer_lines, with the deprecation that goes with it ? More seriously, a

Re: [Numpy-discussion] Remove deprecated skiprows

On 4/5/2011 6:11 PM, Skipper Seabold wrote: > To my mind, skip_headers is a bool I agree. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Remove deprecated skiprows

On Tue, Apr 5, 2011 at 6:05 PM, Pierre GM wrote: > > On Apr 5, 2011, at 11:52 PM, Ralf Gommers wrote: > >> On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold wrote: >>> On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris >>> wrote: Should skiprows be removed?     if skiprows:    

Re: [Numpy-discussion] Remove deprecated skiprows

On Apr 5, 2011, at 11:52 PM, Ralf Gommers wrote: > On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold wrote: >> On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris >> wrote: >>> Should skiprows be removed? >>> >>> if skiprows: >>> warnings.warn(\ >>> "The use of `skiprows` i

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

Hi, On Tue, Apr 5, 2011 at 9:46 AM, Christopher Barker wrote: > On 4/4/11 10:35 PM, Charles R Harris wrote: >>     IIUC, "Ub" is undefined -- "U" means universal newlines, which makes no >>     sense when used with "b" for binary. I looked at the code a ways back, >>     and I can't remember the

Re: [Numpy-discussion] Remove deprecated skiprows

On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold wrote: > On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris > wrote: >> Should skiprows be removed? >> >>     if skiprows: >>     warnings.warn(\ >>     "The use of `skiprows` is deprecated, it will be removed in >> numpy 2.0.\n" \ >>    

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

Hi, On Tue, Apr 5, 2011 at 10:56 AM, Charles R Harris wrote: > > > On Tue, Apr 5, 2011 at 11:45 AM, wrote: >> >> On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris >> wrote: >> > >> > >> > On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker >> > >> > wrote: >> >> >> >> On 4/4/11 10:35 PM, Charle

Re: [Numpy-discussion] Remove deprecated skiprows

On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris wrote: > Should skiprows be removed? > >     if skiprows: >     warnings.warn(\ >     "The use of `skiprows` is deprecated, it will be removed in > numpy 2.0.\n" \ >     "Please use `skip_header` instead.", >     Deprecat

Re: [Numpy-discussion] Remove deprecated skiprows

On Mon, Apr 4, 2011 at 2:20 AM, Charles R Harris wrote: > Should skiprows be removed? > >     if skiprows: >     warnings.warn(\ >     "The use of `skiprows` is deprecated, it will be removed in > numpy 2.0.\n" \ >     "Please use `skip_header` instead.", >     Deprecat

[Numpy-discussion] Installation problem: numpy1.5.1 + python2.7 + virtualenv-1, 5, 1

Hi, I'm trying to install numpy1.5.1 in a virtual environment (virtualenv-1.5.1) on my debian testing box. I'm using python 2.7 installed from a debian package. This is what I get: (venv2.7)vmas@rachael$ python setup.py install Running from numpy source directory.F2PY Version 1 blas_opt_info:

Re: [Numpy-discussion] convert array to tuples?

On 4/5/11 10:52 AM, Sebastian Haase wrote: > How about fixing PIL... I know that there is not a good track record > of getting patches into PIL , > but did you get to the bottom of it and find how draw.line is implemented? no. I haven't. And yes adapting PIL to use the buffer interface for this k

Re: [Numpy-discussion] loadtxt/savetxt tickets

On 04/04/2011 12:38 PM, Charles R Harris wrote: On Mon, Apr 4, 2011 at 11:01 AM, Bruce Southey > wrote: On 04/04/2011 11:20 AM, Charles R Harris wrote: On Mon, Apr 4, 2011 at 9:59 AM, Bruce Southey mailto:bsout...@gmail.com>> wrote: On 03/31/2011

Re: [Numpy-discussion] Problem with np.power in numpy 1.5.1-2

On Tue, Apr 5, 2011 at 8:11 AM, M. wrote: > Hi all, > > I've been using numpy without problems - version .1.4.1-5 - until this > morning, when I upgraded my Debian sid system to numpy 1.5.1-2. A > function that was working that uses np.power > > def get_far_field(self, chi, n): >return np

Re: [Numpy-discussion] convert array to tuples?

Just a suggestion (I am very new to Numpy), but wouldn't draw.line(tuple(points.tolist())) accomplish what you want. Based on my reading, the ndarray.tolist method would return a Python list of elements; then Python's built-in tuple function would complete the conversion. Regards,

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 11:45 AM, wrote: > On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris > wrote: > > > > > > On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker < > chris.bar...@noaa.gov> > > wrote: > >> > >> On 4/4/11 10:35 PM, Charles R Harris wrote: > >> > IIUC, "Ub" is undefined -- "U

Re: [Numpy-discussion] convert array to tuples?

On Tue, Apr 5, 2011 at 1:02 PM, Christopher Barker wrote: > HI folks, > > What's the fastest way to convert a numpy array to tuples? > > Unfortunately, not all packages take arbitrary sequences when they are > expecting a list of tuples. In this case, I'm using PIL's ImageDraw, and > want to do: >

Re: [Numpy-discussion] convert array to tuples?

On Tue, Apr 5, 2011 at 7:02 PM, Christopher Barker wrote: > HI folks, > > What's the fastest way to convert a numpy array to tuples? > > Unfortunately, not all packages take arbitrary sequences when they are > expecting a list of tuples. In this case, I'm using PIL's ImageDraw, and > want to do: >

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris wrote: > > > On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker > wrote: >> >> On 4/4/11 10:35 PM, Charles R Harris wrote: >> >     IIUC, "Ub" is undefined -- "U" means universal newlines, which makes >> > no >> >     sense when used with "b" for

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker wrote: > On 4/4/11 10:35 PM, Charles R Harris wrote: > > IIUC, "Ub" is undefined -- "U" means universal newlines, which makes > no > > sense when used with "b" for binary. I looked at the code a ways > back, > > and I can't remember t

[Numpy-discussion] convert array to tuples?

HI folks, What's the fastest way to convert a numpy array to tuples? Unfortunately, not all packages take arbitrary sequences when they are expecting a list of tuples. In this case, I'm using PIL's ImageDraw, and want to do: draw.line(points) (points is an Nx2 numpy array of ints) but if I p

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On 4/4/11 10:35 PM, Charles R Harris wrote: > IIUC, "Ub" is undefined -- "U" means universal newlines, which makes no > sense when used with "b" for binary. I looked at the code a ways back, > and I can't remember the resolution order, but there isn't any checking > for incompatible

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

SUSE 11.3, python 2.7, gcc 4.3.4, gfortran from gcc 4.6.0, I get two failures on commit 1439a8ddcb2eda20fa102aa44e846783f29c0af3 (head of 1.6.x maintenance branch). --George. == FAIL: Test basic arithmetic function errors --

Re: [Numpy-discussion] Strange behavior of operator *=

On Tue, Apr 5, 2011 at 8:44 AM, Alan G Isaac wrote: > On 4/5/2011 10:37 AM, Nathaniel Smith wrote: > > Yes, this is a fact about Python 'int', not a fact about numpy -- a > > Python 'int' is defined to hold a C 'long', which will be either 32 or > > 64 bits depending on platform. > > > So what is

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Tue, Apr 5, 2011 at 8:12 AM, Charles R Harris wrote: > > > On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker wrote: > >> On 4/4/11 9:03 PM, josef.p...@gmail.com wrote: >> > On Mon, Apr 4, 2011 at 11:42 PM, Charles R Harris >> >> >>>File "/sw/lib/python2.4/site-packages/numpy/lib/_datasource.py"

Re: [Numpy-discussion] Strange behavior of operator *=

On 4/5/2011 10:37 AM, Nathaniel Smith wrote: > Yes, this is a fact about Python 'int', not a fact about numpy -- a > Python 'int' is defined to hold a C 'long', which will be either 32 or > 64 bits depending on platform. So what is the rule for Python 3, where iiuc it can no longer be "a fact abo

Re: [Numpy-discussion] Strange behavior of operator *=

On Tue, Apr 5, 2011 at 6:39 AM, Alan G Isaac wrote: > On 4/5/2011 9:26 AM, François Steinmetz wrote: >> It does not change the dtype, 'int' is just interpreted as 'int64' : > > So the meaning of 'int' is system specific? > >     >>> import numpy as np; a=np.eye(2,dtype='int'); a.dtype >     dtype(

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker wrote: > On 4/4/11 9:03 PM, josef.p...@gmail.com wrote: > > On Mon, Apr 4, 2011 at 11:42 PM, Charles R Harris > > >>>File "/sw/lib/python2.4/site-packages/numpy/lib/_datasource.py", > >>> line 477, in open > >>> return _file_openers[ext](foun

[Numpy-discussion] Problem with np.power in numpy 1.5.1-2

Hi all, I've been using numpy without problems - version .1.4.1-5 - until this morning, when I upgraded my Debian sid system to numpy 1.5.1-2. A function that was working that uses np.power def get_far_field(self, chi, n): return np.sum(self.an[n,1:self.j] * np.power(chi,-np.arange(1,self

Re: [Numpy-discussion] Strange behavior of operator *=

On 5. apr. 2011, at 15.39, Alan G Isaac wrote: > On 4/5/2011 9:26 AM, François Steinmetz wrote: >> It does not change the dtype, 'int' is just interpreted as 'int64' : > > > So the meaning of 'int' is system specific? > import numpy as np; a=np.eye(2,dtype='int'); a.dtype > dtype('int

Re: [Numpy-discussion] Strange behavior of operator *=

On 4/5/2011 9:26 AM, François Steinmetz wrote: > It does not change the dtype, 'int' is just interpreted as 'int64' : So the meaning of 'int' is system specific? >>> import numpy as np; a=np.eye(2,dtype='int'); a.dtype dtype('int32') Alan Isaac ___

Re: [Numpy-discussion] Strange behavior of operator *=

2011/4/5 Alan G Isaac : > On 4/5/2011 5:49 AM, François Steinmetz wrote: >>  >>> a = eye(2, dtype='int') >>  >>> a *= 1.0 >>  >>> a ; a.dtype >> array([[1, 0], >>         [0, 1]]) >> dtype('int64') > > This in-place (!) multiplication should not change > the dtype of a.  I suspect you did not exact

Re: [Numpy-discussion] How to create structured char arrays?

On 04/04/2011 02:30 PM, Derek Homeier wrote: > Hi Bruce, > >> I think that I have resolved my issue down to creating a structured >> string array. >> I am using numpy version '2.0.0.dev-3c338cb'. >> >> Without a structured array, it should be a 2 by 2 array: > np.array([('a','b'),('c','d')]) >>

Re: [Numpy-discussion] Strange behavior of operator *=

On 4/5/2011 5:49 AM, François Steinmetz wrote: > >>> a = eye(2, dtype='int') > >>> a *= 1.0 > >>> a ; a.dtype > array([[1, 0], > [0, 1]]) > dtype('int64') This in-place (!) multiplication should not change the dtype of a. I suspect you did not exactly cut and paste... Alan Isaac ___

Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2

Superpack is OK on Windows Vista 64bit with Python 2.7 32bit. Alan Isaac Ran 2993 tests in 25.707s OK (KNOWNFAIL=9, SKIP=5) Running unit tests for numpy NumPy version 1.6.0b2 NumPy is installed in c:\Python27\lib\site-packages\numpy Python version 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.150

Re: [Numpy-discussion] Strange behavior of operator *=

Ok, thanks for the clarification ! François On Tue, Apr 5, 2011 at 11:55, Matthieu Brucher wrote: > Indeed, it is not. In the first case, you keep your original object and > each (integer) element is multiplied by 1.0. In the second example, you are > creating a temporary object a*x, and as x is

Re: [Numpy-discussion] Strange behavior of operator *=

Indeed, it is not. In the first case, you keep your original object and each (integer) element is multiplied by 1.0. In the second example, you are creating a temporary object a*x, and as x is a float and a an array of integers, the result will be an array of floats, which will be assigned to a. M

[Numpy-discussion] Strange behavior of operator *=

Hi all, I have encountered the following strangeness : >>> from numpy import * >>> __version__ '1.5.1' >>> a = eye(2, dtype='int') >>> a *= 1.0 >>> a ; a.dtype array([[1, 0], [0, 1]]) dtype('int64') >>> a = a * 1.0 >>> a ; a.dtype array([[ 1., 0.], [ 0., 1.]]) dtype('float64') So,

[Numpy-discussion] bug with numpy nanargmax/nanargmin

>>> from numpy import * >>> nanargmax([nan,nan]) nan # ok >>> nanargmax([nan,nan],0) nan # ok >>> nanargmax([[1,nan],[1,nan]],0) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.6/site-packages/numpy/lib/function_base.py", line 1606