[Numpy-discussion] np.{bool,float,int} deprecation

[Sebastian Berg]

On Sun, 2020-12-13 at 19:00 +1100, Juan Nunez-Iglesias wrote:
> 
> 
> > On 13 Dec 2020, at 6:25 am, Sebastian Berg <
> > sebastian at sipsolutions.net> wrote:
> > 
> > But "default" in NumPy really doesn't mean a whole lot?  I can
> > think of
> > three places where "defaults" exists:
> 
> Huh? There are platform-specific defaults for literally every array
> creation function in NumPy?
> 
> In [1]: np.array([4, 9]).dtype
> Out[1]: dtype('int64')
<snip>
> The list goes on…
> 

I should have been more clear about this and my opinion on it:

1. The whole list comes down to my point 1: when confronted with a
Python integer, NumPy will typically use a C-long [1].
Additionally, `dtype=int` is always the same as long:
`np.dtype(int) == np.dtype("long")`.

The reason why I see that as a single point, is that it is defined in a
single place in C [1].  (The `np.dtype(int)` is a second place.)


2. I agree with Ralf that this is "random". On the same computer you
can easily get a wrong result for the identical code because you boot
into windows instead of linux [2]. `long` is not a good default! It is
32bit on windows and 64bit on (64bit) linux! That should confuse the
majority of our users (and probably many who are aware of C integer
types).
Good defaults are awesome, but I just can't see how `long` is a good
default.  There were good reasons for it on Python 2, but that is not
relevant anymore.


3. I think that `intp` would be a much saner default for most code. It
gives a system dependent result, but two points are in its favor:

   * NumPy generates `intp` in quite a lot of places
   * It is always safe (and fast) to index arrays with `intp`


> And, indeed, mixing types can cause implicit casting, and thus both
> slowness and unexpected type promotion, which brings with it its own
> bugs… Again, I think it is valuable to have syntax to express
> `np.zeros(…, dtype=<whatever-dtype-np.array(…)-would-give-for-my-
> data>)`.

Yes, it is valuable, but I am unsure we should advise to use it...

Cheers,

Sebastian



[1] Currently defined here:
https://github.com/numpy/numpy/blob/7a42940e610b77cee2f98eb88aed5e66ef6d8c2a/numpy/core/src/multiarray/abstractdtypes.c#L16-L45
Which will use `long` normally, but `long long` (64bit) if that fails
and even `unsigned long long` if *that* fails also.


[2] I would not be surprised if there are quite a few libraries with
bugs for very large arrays, that are simply not found yet, because
nobody tried to run the code on very large arrays on a windows
workstation yet.



> Juan.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201213/e197e286/attachment.sig>