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 stdin, line 1, in module
File
/usr/local/lib/python2.6/site-packages/numpy/lib/function_base.py,
line 1606, in
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, in this case a *= x
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.
Ok, thanks for the clarification !
François
On Tue, Apr 5, 2011 at 11:55, Matthieu Brucher
matthieu.bruc...@gmail.comwrote:
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
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
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')])
array([['a',
2011/4/5 Alan G Isaac alan.is...@gmail.com:
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
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
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('int32')
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] *
On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker chris.bar...@noaa.gov 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
On Tue, Apr 5, 2011 at 6:39 AM, Alan G Isaac alan.is...@gmail.com 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
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 about
On Tue, Apr 5, 2011 at 8:12 AM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker chris.bar...@noaa.govwrote:
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
On Tue, Apr 5, 2011 at 8:44 AM, Alan G Isaac alan.is...@gmail.com 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.
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
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 flags.
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
On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker
chris.bar...@noaa.govwrote:
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
On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris
charlesr.har...@gmail.com 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 means universal newlines, which makes
no
On Tue, Apr 5, 2011 at 7:02 PM, Christopher Barker
chris.bar...@noaa.gov 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
On Tue, Apr 5, 2011 at 1:02 PM, Christopher Barker
chris.bar...@noaa.gov 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
On Tue, Apr 5, 2011 at 11:45 AM, josef.p...@gmail.com wrote:
On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris
charlesr.har...@gmail.com 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,
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,
On Tue, Apr 5, 2011 at 8:11 AM, M. infinity.probabil...@gmail.com 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,
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
On Mon, Apr 4, 2011 at 2:20 AM, Charles R Harris
charlesr.har...@gmail.com 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.,
Hi,
On Tue, Apr 5, 2011 at 10:56 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Apr 5, 2011 at 11:45 AM, josef.p...@gmail.com wrote:
On Tue, Apr 5, 2011 at 1:20 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Apr 5, 2011 at 10:46 AM, Christopher Barker
On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold jsseab...@gmail.com wrote:
On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Should skiprows be removed?
if skiprows:
warnings.warn(\
The use of `skiprows` is deprecated, it will be
Hi,
On Tue, Apr 5, 2011 at 9: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 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
On Apr 5, 2011, at 11:52 PM, Ralf Gommers wrote:
On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold jsseab...@gmail.com wrote:
On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Should skiprows be removed?
if skiprows:
warnings.warn(\
On Tue, Apr 5, 2011 at 6:05 PM, Pierre GM pgmdevl...@gmail.com wrote:
On Apr 5, 2011, at 11:52 PM, Ralf Gommers wrote:
On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold jsseab...@gmail.com wrote:
On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Should
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
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, as
On Tue, Apr 5, 2011 at 5:56 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Tue, Apr 5, 2011 at 9: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 means universal newlines, which makes no
sense when
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
==
FAIL: test_iterator.test_iter_broadcasting_errors
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
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
Table name='None' rows=3 fields=2
name = [aaa,bbb,ccc]
p = atpy.Table()
On Tue, Apr 5, 2011 at 5:52 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold jsseab...@gmail.com wrote:
On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Should skiprows be removed?
if skiprows:
On Tue, Apr 5, 2011 at 18:20, Wes McKinney wesmck...@gmail.com 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
Hi,
On Tue, Apr 5, 2011 at 4:12 PM, Christopher Barker
chris.bar...@noaa.gov 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
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
==
FAIL:
On Tue, Apr 5, 2011 at 7:32 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Apr 5, 2011 at 18:20, Wes McKinney wesmck...@gmail.com wrote:
FYI:
http://docs.python.org/library/warnings.html
DeprecationWarning Base category for warnings about deprecated
features (ignored by default).
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
On 4/5/2011 6:46 PM, Mark Wiebe wrote:
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu
On Tue, Apr 5, 2011 at 7:21 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 6:46 PM, Mark Wiebe wrote:
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at
On 4/5/2011 7:44 PM, Mark Wiebe wrote:
On Tue, Apr 5, 2011 at 7:21 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/5/2011 6:46 PM, Mark Wiebe wrote:
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu
48 matches
Mail list logo
