Colin J. Williams wrote:

The following seems to show that the default data type for the numarray elements is Int32:

It is, and I thought my original message said that. I was talking about Numeric3, where the default type for zeros() is 'd' (Float64 in numarray parlance).

konrad.hinsen@laposte.net wrote:

My main argument is a different one: consistency.

I see zeros() as an array constructor, a shorthand for calling array() with an explicit list argument.

Ah, but array(10*[0]) returns an integer array, and array(10*[0.]) returns a double. Which should zeros() be equivalent to?

On Mar 28, 2005, at 10:43 AM, Robert Kern wrote:

Stephen Walton wrote:

...

zeros() in Numeric3 defaults to typecode='d' while in numarray it defaults to typecode=None, which in practice means 'i' by default. Is this deliberate? Is this desirable? I'd vote for zeros(), ones() and the like to default to 'i' or 'f' rather than 'd' in the interest of space and speed.

For zeros() and ones(), I don't think space and speed are going to be affected by the default typecode. In my use of these functions, I almost always need a specific typecode. If I use the default, it's because I actually need the default typecode. Unfortunately, I almost always want Float and not Int, so all of my code is littered with

zeros(shape, Float)

I'll bet Travis's code looks the same.

I would *love* to be able to spell these things like

Float.zeros(shape) UInt8.ones(shape) Complex32.array(other) ...

This is an odd thought but why not: Float(shape) # defaults to 0 UInt(shape, value=1) I forget if it was proposed to make the type object a constructor for arrays in which case this may conflict with the usage of converting the argument of the callable form to an array, i.e., Float((2,3)) --> array([2.,3.], typecode=Float) # or whatever the name of the type parameter becomes

Francesc Altet wrote:

A Dilluns 28 Març 2005 18:18, Perry Greenfield va escriure:

...

This is an odd thought but why not:

Float(shape) # defaults to 0 UInt(shape, value=1)

I forget if it was proposed to make the type object a constructor for arrays in which case this may conflict with the usage of converting the argument of the callable form to an array, i.e.,

Float((2,3)) --> array([2.,3.], typecode=Float) # or whatever the name of the type parameter becomes

Well, why not:

Array(shape, type=Float, defvalue=None)

In the end, all three paramters are used to univoquely determine the Array object. Moreover, "defvalue = None" would be a synonymous of the recently introduced "empty" factory.

My thought was to not deal with typecode keywords at all and put more responsibility on the typecode objects for general constructor-type operations. In this vein, though, I suggest the spelling Float.new(shape, value=None) # empty Float.new(shape, value=0) # zeros Float.new(shape, value=1) # ones value defaults to None. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

Stephen Walton wrote:

Robert Kern wrote:

...

Float.new(shape, value=None) # empty Float.new(shape, value=0) # zeros Float.new(shape, value=1) # ones

Uhm, my first reaction to this kind of thing is "ugh," but maybe I'm just not thinking in the correct OO mode. Is this any better than zeros() and ones()? For that matter, is it any better than

x=zeros(shape) x=any_old_scalar

x[:] = any_old_scalar you mean? Perhaps not, *if* I need the default type, which I rarely do. And when I do need the default type, and I'm coding carefully, I will add the type anyways to be explicit. I *do* think that x = CFloat.new(shape, 2j*pi) is better than x = empty(shape, type=CFloat) x[:] = 2j*pi I don't think there's much OO in it. The implementations won't change, really. It's more a matter of aesthetics of the API. I like it for much the same reasons that transpose(array) et al. were folded into methods of arrays. Also, with Perry's and Francesc's suggestions, it collapses three very similar functions into one.

Having said that, the main reason I use zeros() in MATLAB is to preallocate space.

I use it the same in Python. Sometimes, I'm going to be replacing all of the values (in which case I would use empty()), but often I only need to sparsely replace values. Usually, the "background" value ought to be 0, but occasionally, things get weirder. But, this isn't a particularly important issue. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter