On Sat, 2020-12-12 at 12:34 +1100, Juan Nunez-Iglesias wrote: > > > I agree. I think we should recommend sane, descriptive names that > > do the right thing. So ideally we'd have people spell their dtype > > specifiers as > > dtype=bool # or np.bool > > dtype=np.float64 > > dtype=np.int64 > > dtype=np.complex128 > > The names with underscores at the end make little sense from a UX > > perspective. And the C equivalents (single/double/etc) made sense > > 15 years ago, but with the user base of today - the majority of > > whom will not know C fluently or at all - also don't make too much > > sense. > > > > The `dtype=int` or `dtype=np.int_` behaviour flopping between 32 > > and 64 bits is likely to be a pitfall much more often than it is > > what the user actually needs, so shouldn't be recommended and > > probably deserves a warning in the docs. > > I kinda disagree with this. I want to have a way to say, give me an > array of the same type as the default NumPy type (for either ints or > floats). This will prevent casting back and forth as different arrays > are combined. In other words, as long as NumPy itself flips back and > forth (depending on locale), I think users will in many cases want to > flip back and forth with it?
But "default" in NumPy really doesn't mean a whole lot? I can think of
three places where "defaults" exists:
1. `np.array([1])` will default to a C-long (as will `np.uint8(1) + 1`)
2. Sum and product upcast to C-long (and pretty much only those):
np.sum(np.arange(10, dtype=np.int8))
np.product(np.arange(10, dtype=np.int8))
3. NumPy uses `np.intp` for all indexing operations internally and
some functions many functions which return integers related to
indexing (e.g. `np.nonzero()`). [1]
The first two points have no logic at all besides: windows thinks long
is always 32bit and others think long is 64bit on 64bit systems. The
last point does have some logic.
Generally, the only reason to stick to a certain type would be that
mixing types can be slower (using a non `intp` to index or doing math
with a mix of 32bit and 64bit integers).
From a library perspective, I wonder how often you actually expect a
"default integer" input, as opposed to 32bit or 64bit depending on the
whims of the user; or `intp` because it is "indexing related".
It would be interesting to see if we can change the default at some
point. It might also be tricky: There may be quite a bit of code
expecting `long` (e.g. Cython extensions or `scipy.special` may or may
not notice such a change).
Cheers,
Sebastian
[1] intp is technically intptr_t in C, while indexing only requires an
ssize_t I think. That probably matters on no currently supported
systems, but system where it matters do exist (OpenVMS is one that just
came up, and we may support in the future).
>
> Juan.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
