On Fri, 2020-12-11 at 11:35 +0100, Ralf Gommers wrote: > On Thu, Dec 10, 2020 at 9:00 PM Sebastian Berg < > sebast...@sipsolutions.net> > wrote:
<snip> > > Just deprecation `np.int` may make sense. That will already raise > awareness, and leaving `np.float` as-is may prevent a lot of churn. > And we > could then still deprecate `np.float` later. I also don't feel > strongly > about `float` either way though. > > I'm not sure why you'd specifically touch `long`, it's not really > relevant > and it's not a builtin. > `np.long is np.int is int` as it was a builtin on Python 2. But it looks like a C-long. In `dtype=` usage it actually ends up being a C-long (but it might even be nice to consider modifying the default `int` on windows at some point. At that point the "long" alias would be very confusing). OTOH, right now the only way to spell C-long is with `np.int_` which doesn't help. Cheers, Sebastian > Cheers, > Ralf > > To be honest, I don't mind either way, so any stronger opinion will > tip > > the scale for me personally (my default currently is to update the > > release notes to recommend the more descriptive names). > > > > There are probably more doc updates that would be nice, I will > > suggest > > updating a separate issue for that. > > > > > > > Right now, my main take-away from the discussion is that it would > > > be > > > > good to clarify the release notes a bit more. > > > > > > > > Using `float` for a dtype seems fine to me, but I prefer > > > > mentioning > > > > `np.float64` over `np.float_`. > > > > For integers, I wonder if we should also suggest `np.int64`, > > > > even – > > > > or > > > > because – if the default integer on many systems is currently > > > > `np.int_`? > > > > > > > > > > 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. > > > > Right, there is one slight trickery because `np.intp` is often a > > great > > integer dtype to use, because it is the integer that NumPy uses for > > all > > things related to indexing and array sizes. > > (I would be happy to dig out my PR making `np.intp` the default > > NumPy > > integer.) > > > > Cheers, > > > > Sebastian > > > > > > > > > > Cheers, > > > Ralf > > > > > > > > > > > > > > > > > > > > np.int_ and np.float_ have fixed precision, which makes them > > > > > somewhat > > > > > different from the builtin types. NumPy has a whole bunch of > > > > > different > > > > > precisions for integer and floats, so this distinction > > > > > matters. > > > > > > > > > > In contrast, there is only one boolean dtype in NumPy, which > > > > > matches > > > > > Python's bool. So we wouldn't have to worry, for example, > > > > > about > > > > > whether a > > > > > user has requested a specific precision explicitly. This > > > > > comes up > > > > > in > > > > > issues > > > > > like type-promotion where libraries like JAX and PyTorch have > > > > > special > > > > > case > > > > > logic for most Python types vs NumPy dtypes (but booleans are > > > > > the > > > > > same for > > > > > both): > > > > > https://jax.readthedocs.io/en/latest/type_promotion.html > > > > > > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > 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
