I think it's time for the 1.0.2 release of NumPy. What outstanding issues need to be resolved before we do it? Hopefully, we can do it by the end of the week. -Travis
One question, which may be an issue: Should ones, zeros and empty be generating arrays of floats by default now? Gary R. Travis Oliphant wrote:
I think it's time for the 1.0.2 release of NumPy.
What outstanding issues need to be resolved before we do it?
Hopefully, we can do it by the end of the week.
-Travis
On Tue, 30 Jan 2007, Gary Ruben apparently wrote:
One question, which may be an issue: Should ones, zeros and empty be generating arrays of floats by default now?
import numpy as n z = n.zeros((2,2)) z.dtype dtype('float64') o = n.ones((2,2)) o.dtype dtype('float64') e = n.empty((2,2)) e.dtype dtype('float64') n.__version__ '1.0'
hth, Alan Isaac
Thanks Alan & Chris, My apologies. I was trying ones(), zeros() and empty() in ipython 0.7.2 with the -pylab option and getting the wrong functions. On my system, ipython -pylab imports the namespace of the oldnumeric wrapper versions of ones(), zeros() and empty() and I had assumed these were the core numpy versions. Maybe this has been changed in ipython 0.7.3. Gary R. Alan G Isaac wrote:
On Tue, 30 Jan 2007, Gary Ruben apparently wrote:
One question, which may be an issue: Should ones, zeros and empty be generating arrays of floats by default now?
import numpy as n z = n.zeros((2,2)) z.dtype dtype('float64') o = n.ones((2,2)) o.dtype dtype('float64') e = n.empty((2,2)) e.dtype dtype('float64') n.__version__ '1.0'
hth, Alan Isaac
Thanks Alan & Chris,
My apologies. I was trying ones(), zeros() and empty() in ipython 0.7.2 with the -pylab option and getting the wrong functions. On my system, ipython -pylab imports the namespace of the oldnumeric wrapper versions of ones(), zeros() and empty() and I had assumed these were the core numpy versions. Maybe this has been changed in ipython 0.7.3.
Hmm ... it doesn't appear to be so: In [2]: import IPython In [3]: IPython.__version__ Out[3]: '0.7.4.svn.r2010' In [4]: ones? Type: function Base Class: <type 'function'> String Form: <function ones at 0x34ad8b0> Namespace: Interactive File: /opt/local/lib/python2.4/site-packages/numpy/ oldnumeric/functions.py Definition: ones(shape, typecode='l', savespace=0, dtype=None) Docstring: ones(shape, dtype=int) returns an array of the given dimensions which is initialized to all ones. Is something that should change/be reported to the ipython ML maybe? -steve
Actually, I just realised; it's not an ipython problem. I think it's a matplotlib problem. I'll report it there. Gary R. Steve Lianoglou wrote:
Thanks Alan & Chris,
My apologies. I was trying ones(), zeros() and empty() in ipython 0.7.2 with the -pylab option and getting the wrong functions. On my system, ipython -pylab imports the namespace of the oldnumeric wrapper versions of ones(), zeros() and empty() and I had assumed these were the core numpy versions. Maybe this has been changed in ipython 0.7.3.
Hmm ... it doesn't appear to be so:
On 1/31/07, Gary Ruben <gruben@bigpond.net.au> wrote:
Actually, I just realised; it's not an ipython problem. I think it's a matplotlib problem. I'll report it there.
Until mpl drops support for the compatibility layers, you may want to set up a simple pylab profile. In ~/.ipython make a file called 'ipythonrc-pylab' consisting of: ####### # Load default config include ipythonrc # Add single-line python statements here execute from numpy import * ######## Since pylab does a 'from .num?. import *' this will ensure that the top-level visible functions are the current numpy ones, not the compatibility layer ones. You then start things with: ipython -pylab -p pylab and you'll get: In [1]: zeros? Type: builtin_function_or_method Base Class: <type 'builtin_function_or_method'> Namespace: Interactive Docstring: zeros((d1,...,dn),dtype=float,order='C') Return a new array of shape (d1,...,dn) and type typecode with all it's entries initialized to zero. Not ideal, but it's a little hack that will work in practice until we finish crossing the muddy river of backwards compatibility. Cheers, f
Thanks Fernando, Good idea. I'll apply your suggestion. Gary Fernando Perez wrote:
On 1/31/07, Gary Ruben <gruben@bigpond.net.au> wrote:
Actually, I just realised; it's not an ipython problem. I think it's a matplotlib problem. I'll report it there.
Until mpl drops support for the compatibility layers, you may want to set up a simple pylab profile. In ~/.ipython make a file called 'ipythonrc-pylab' consisting of: <snip> Not ideal, but it's a little hack that will work in practice until we finish crossing the muddy river of backwards compatibility.
Cheers,
f
Gary Ruben wrote:
One question, which may be an issue: Should ones, zeros and empty be generating arrays of floats by default now?
import numpy as N
N.ones((3,)).dtype dtype('float64')
N.zeros((3,)).dtype dtype('float64')
N.__version__ '1.0.1'
-Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Travis Oliphant schrieb:
I think it's time for the 1.0.2 release of NumPy.
What outstanding issues need to be resolved before we do it?
Hi, I just used real_if_close for the first time, and promptly discovered that it turns matrix input into array output:
import numpy as n n.__version__ '1.0.1' n.real_if_close(n.mat(1)) array([[1]])
Maybe it's something for 1.0.2, or should I file a ticket? I could also do another round of systematic searches for other functions that still behave like this, but I'm afraid not before 1.0.2 (if that happens this weekend). Thanks, Sven
participants (7)
-
Alan G Isaac -
Christopher Barker -
Fernando Perez -
Gary Ruben -
Steve Lianoglou -
Sven Schreiber -
Travis Oliphant