Hi,
I am wondering a bit about the the behaviour of logspace:
Definition: numpy.logspace(start, stop, num=50, endpoint=True, base=10.0)
Reading this I would assume that
numpy.logspace(10**-12, 0.0, 100)
gives 100 values, from start=10**-12 to stop=0.0,
equispaced on a logarithmic scale.
But
I guess this is a change which would just break too much code. And if
the default type should by changed for these functions, why not also for
array constructors?
On the other hand, many people probably use Numpy almost exclusively
with Float64's. A convenient way to change the default type
Have I done something silly here, or is this a bug?
Opteron 64-bit, r2631 SVN.
In [4]: depths_s2 = empty(shape=(5,),dtype=float)
In [5]: depths_s2.fill(2.e5)
In [6]: depths_s2
Out[6]: array([ 20., 20., 20., 20., 20.])
In [11]: depths_s2 =
Hi,
Opteron 64-bit, r2631 SVN.
In [4]: depths_s2 = empty(shape=(5,),dtype=float)
In [5]: depths_s2.fill(2.e5)
In [6]: depths_s2
Out[6]: array([ 20., 20., 20., 20., 20.])
In [11]: depths_s2 = (empty(shape=(5,),dtype=float)).fill(2.e5)
In [12]: print depths_s2
None
+1 for float64.
I'll teach Introduction to Numerical Linear Algebra next term and I will
use numpy!
Best,
Paulo
--
Paulo José da Silva e Silva
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil
e-mail:
Travis Oliphant wrote:
Nonetheless, I would support the creation of a module called something
like defaultfloat or some-other equally impressive name ;-) which
contained floating-point defaults of these functions (with the same
names).
I'd also like to see a way to make the constructors
While it is hard to read too much into numbers, this tells me that there
are about 10,000 current users of Numeric/Numarray who have not even
*tried* NumPy. In fact, Numarray downloads of 1.5.1 went up
significantly from its earlier releases. Why is that? It could be
that many of the
MDP version 2.0 has been released!
What is it?
---
Modular toolkit for Data Processing (MDP) is a data processing
framework written in Python.
From the user's perspective, MDP consists of a collection of trainable
supervised and unsupervised algorithms that can be combined into data
On Fri, 30 Jun 2006 03:33:56 -0600
Travis Oliphant [EMAIL PROTECTED] wrote:
One thing I've learned about Open Source development is that it can be
hard to figure out exactly what is bothering people and get good
critical feedback: people are more likely to just walk away with their
I am in the process of implementing an image processing algorithm that requires following rays extending outwards from a starting point and calculating the intensity derivative at each point. The idea is to find the point where the difference in intensity goes beyond a particular threshold.
On 6/29/06, Alan G Isaac [EMAIL PROTECTED] wrote:
On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
Please make any comments or voice major concerns
A rather minor issue, but I would just like to make sure
that a policy decision was made not to move to a float
default for identity(),
On Fri, Jun 30, 2006 at 07:15:39AM -0700, Keith Goodman wrote:
So far the vote is 8 for float, 1 for int.
+1 for float64.
Glen
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM
Regarding choice of float or int for default:
The number one priority for numpy should be to unify the three disparate
Python numeric packages. Whatever choice of defaults facilitates that is
what I support.
Personally, given no other constraints, I would probably just get rid of
the
+1 for float64
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
On 6/30/06, Erin Sheldon [EMAIL PROTECTED] wrote:
http://www.numpy.org/-- is empty
I see this is now pointing to the sourceforge site. Must have been a
glitch there earlier as it was returning an empty page.
Using Tomcat but need to do more? Need to support web services, security?
Get
On 6/30/06, Scott Ransom [EMAIL PROTECTED] wrote:
+1 for float64 for me as well.
+1 for float64
I have lots of code overriding the int defaults by hand which were
giving me grief with hand-written extensions (which were written
double-only for speed reasons). I'll be happy to clean this up.
I
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
...
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't be a problem for anyone.
Is this a joke? Did anyone ever measured the
Joris De Ridder wrote:
On Friday 30 June 2006 16:29, Erin Sheldon wrote:
[ES]: snip the pages
[ES]:
[ES]:http://numeric.scipy.org/ -- Looks antiquated
[ES]:
[ES]: are not helping.
My opinion too. If that page is the first page you learn about NumPy,
you won't have
Sasha wrote:
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
...
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't be a problem for anyone.
Is this a joke? Did
On 6/30/06, Sasha [EMAIL PROTECTED] wrote:
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
...
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't be a problem for anyone.
I've got to say +1 for Float64 too. I write a lot of numpy code, and
this bites me at least once a week. You'd think I'd learn better, but
it's just so easy to screw this up when you have to switch back and
forth between matlab (which I'm forced to TA) and numpy (which I use for
Real Work).
Tim Hochberg wrote:
Regarding choice of float or int for default:
The number one priority for numpy should be to unify the three disparate
Python numeric packages. Whatever choice of defaults facilitates that is
what I support.
+10
Personally, given no other constraints, I would
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
Besides, decent unit tests will catch these problems. We
all know that every scientific code in existence is unit
tested to the smallest routine, so this shouldn't be
a problem for anyone.
On Fri, 30 Jun 2006, Sasha apparently wrote:
On 6/30/06, Sasha [EMAIL PROTECTED] wrote:
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
...
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't be a problem for anyone.
Since I was almost alone with my negative vote on the float64 default,
I decided to give some more thought to the issue.
I agree there are strong reasons to make the change. In addition to
the points in the original post, float64 type is much more closely
related to the well-known Python float
On Fri, 30 Jun 2006 14:42:33 -0400
Jonathan Taylor [EMAIL PROTECTED] wrote:
+1 for some sort of float. I am a little confused as to why Float64
is a particularly good choice. Can someone explain in more detail?
Presumably this is the most sensible ctype and translates to a python
float
Robert Kern wrote:
Travis Oliphant wrote:
Comments?
Whatever else you do, leave arange() alone. It should never have accepted
floats
in the first place.
Actually, Robert makes a good point. arange with floats is
problematic. We should direct people to linspace instead of
On Fri, Jun 30, 2006 at 01:25:23PM -0600, Travis Oliphant wrote:
Robert Kern wrote:
Whatever else you do, leave arange() alone. It should never have accepted
floats
in the first place.
Actually, Robert makes a good point. arange with floats is
problematic. We should direct people
Scott Ransom wrote:
On Fri, Jun 30, 2006 at 01:25:23PM -0600, Travis Oliphant wrote:
Robert Kern wrote:
Whatever else you do, leave arange() alone. It should never have accepted
floats
in the first place.
Actually, Robert makes a good point. arange with floats is
When an array is printed, the numbers line up in nice columns (if
you're using a fixed-width font):
array([[0, 0],
[0, 0]])
But for matrices the columns do not line up:
matrix([[0, 0],
[0, 0]])
Using Tomcat but need to do more? Need to support web services, security?
Get stuff
On Fri, 30 Jun 2006 12:35:35 -0400
Sasha [EMAIL PROTECTED] wrote:
On 6/30/06, Fernando Perez [EMAIL PROTECTED] wrote:
...
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't
Robert Kern wrote:
It's arange(0.0, 1.0, 0.1) that I think causes the most problems with arange
and
floats.
actually, much to my surprise:
import numpy as N
N.arange(0.0, 1.0, 0.1)
array([ 0. , 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9])
But I'm sure there are other examples
On 6/30/06, David M. Cooke [EMAIL PROTECTED] wrote:
On Fri, 30 Jun 2006 13:37:01 -0700
Keith Goodman [EMAIL PROTECTED] wrote:
When an array is printed, the numbers line up in nice columns (if
you're using a fixed-width font):
array([[0, 0],
[0, 0]])
But for matrices the
It is not as bad as I thought, but there is certainly room for improvement.
File `numpy/core/src/multiarraymodule.c'
Lines executed:63.56% of 3290
File `numpy/core/src/arrayobject.c'
Lines executed:59.70% of 5280
File `numpy/core/src/scalartypes.inc.src'
Lines executed:31.67% of 963
File
Software developers also use coverage testing in concert with
testsuites, to make sure software is actually good enough for a
release. -- Gcov Manual
I think if we can improve the test coverage, it will speak volumes
about the quality of numpy.
Does anyone know if it is possible to instrument
Jonathan Taylor wrote:
In some earlier code (at least one of) the following worked fine. I
just want
to get a new type that is a byteswap of, say, float64 because I want to
memmap an array with a non-native byte order.
Any suggestions?
Last year the array scalars (like float64) were
-- Forwarded message --
From: Alexander Belopolsky [EMAIL PROTECTED]
Date: Jun 30, 2006 7:01 PM
Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0
To: David M. Cooke [EMAIL PROTECTED]
Cc: Fernando Perez [EMAIL PROTECTED],
numpy-discussion@lists.sourceforge.net
On
On 7/1/06, Eric Jonas [EMAIL PROTECTED] wrote:
On Fri, 2006-06-30 at 12:35 -0400, Sasha wrote:
Besides, decent unit tests will catch these problems. We all know
that every scientific code in existence is unit tested to the smallest
routine, so this shouldn't be a problem for anyone.
38 matches
Mail list logo
