> the > latter would seem consistent with the "principle of least surprise" when > moving from a typed language to > NumPy work perhaps, though arguably slightly less user-friendly if naively > doing some operations with > a less formal view of typing (new Python user messing around with NumPy?)
fwiw, my rationale here is that many (most?) beginners will eventually become intermediate-to-advanced, at which point purity becomes increasingly important. It is often easier to explain a "pure" principle to a beginner than it is to navigate around magic behaviour as an expert. At scikit-image tutorials we often begin by having the users overflow a uint8 image, then we explain why that's the case and how to work around it. We have also increasingly encountered users surprised/annoyed that scikit-image blew up their uint8 to a float64, using 8x the RAM. > JAX was mentioned, and their dtype promotion docs are quite nice My God! They are awesome. Hadn't seen them before. For reference: https://jax.readthedocs.io/en/latest/design_notes/type_promotion.html I certainly wouldn't mind if NumPy adopted these wholesale. Juan. On Mon, 21 Feb 2022, at 9:39 PM, Tyler Reddy wrote: > I added a few comments on the PR. The main comments of substance I had boil > down to: > - consistency with other programming languages/major frameworks (perhaps a > few more "examples of consistency" for the new approach with others > may help strengthen the arguments?)--I know JAX was mentioned, and their > dtype promotion docs are quite nice > - one thing I struggled with in deciding if some of the "new behaviors" were > nicer was the tension between > protecting from accidental overflow vs. a more "purist" view that types > should be preserved more strictly; the > latter would seem consistent with the "principle of least surprise" when > moving from a typed language to > NumPy work perhaps, though arguably slightly less user-friendly if naively > doing some operations with > a less formal view of typing (new Python user messing around with NumPy?) > > On Mon, 21 Feb 2022 at 16:35, Sebastian Berg <sebast...@sipsolutions.net> > wrote: >> Hi all, >> >> NumPy has awkward behaviour when it comes to promotion with 0-D arrays, >> and Python scalars. This is both a technical challenge (numpy needs to >> inspect the values where it shouldn't), as well as surprising for >> users. >> >> Roughly speaking, I have made a proposal under the 3 points: >> * NumPy scalars and NumPy arrays always behave the same. >> * A NumPy array always respects the dtype >> * A Python scalar is "weak" so that uint8_arr + 3 returns a uint8_arr >> >> The NEP is here: >> https://25105-908607-gh.circle-artifacts.com/0/doc/neps/_build/html/nep-0050-scalar-promotion.html >> >> But please refer to the PR, since above may go away or get outdated: >> https://github.com/numpy/numpy/pull/21103 >> >> >> Note that I have not 100% made up my mind on these, because some >> alternatives exist which may give a somewhat easier transition. >> Because of this, this is a very early draft (expect large >> changes/rewrite), but some feedback/input may go a long way to make >> sure we keep moving on this project. >> >> For those aware of the issues, it probably makes sense to skip ahead to >> the "Alternatives" section. I do expect that a large refactor/rewrite >> will be necessary, but need some feedback to keep moving. >> >> >> I had send the poll recently: >> https://discuss.scientific-python.org/t/poll-future-numpy-behavior-when-mixing-arrays-numpy-scalars-and-python-scalars/202 >> >> just to say, I have not completely ignored it, although (as expected) >> the results do not give a very simple answer. Many agree with the >> choices I made, but some also seem to prefer "strong" Python types, or >> more special handling of NumPy scalars. >> >> >> Please do not hesitate to give opinions! I am not sure we can find a >> clear "obviously right" solution. Especially since there are tough >> backwards compatibility choices (even if most users are likely not to >> notice). So any input is appreciated. >> >> Cheers, >> >> Sebastian >> >> >> _______________________________________________ >> NumPy-Discussion mailing list -- numpy-discussion@python.org >> To unsubscribe send an email to numpy-discussion-le...@python.org >> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >> Member address: tyler.je.re...@gmail.com > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: j...@fastmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
