Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Sasha <nd...@ma...>]

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 than int32 to Python long.

For example no-one would be surprised by either
>>> float64(0)/float64(0)
nan

or

>>> float(0)/float(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ZeroDivisionError: float division

but

>>> int32(0)/int32(0)
0

is much more difficult to explain.

As is
>>> int32(2)**32
0

compared to

>>> int(2)**32
4294967296L

In short, arrays other than float64 are more of the hard-hat area and
their properties may be surprising to the novices.  Exposing novices
to non-float64 arrays through default constructors is a bad thing.

Another argument that I find compelling is that we are in a now or
never situation.  No one expects that their Numeric or numarray code
will work in numpy 1.0 without changes, but I don't think people will
tolerate major breaks in backward compatibility in the future
releases.

If we decide to change the default, let's do it everywhere including
array constructors and arange.  The later is more controversial, but I
still think it is worth doing (will give reasons in the future posts).

Changing the defaults only in some functions or providing overrides to
functions will only lead to more confusion.

My revised vote is -0.



On 6/30/06, Eric Jonas <jo...@mw...> wrote:
> 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).
>
>                 ...Eric