On Fri, Mar 29, 2024 at 8:39 AM Jim Pivarski <jpivar...@gmail.com> wrote:
> On Fri, Mar 29, 2024 at 8:07 AM Steven G. Johnson <stev...@mit.edu> wrote: > >> Should a dtype=object array be treated more like Python lists for type >> detection/coercion reasons? Currently, they are treated quite differently: >> >>> np.isfinite([1,2,3]) >> array([ True, True, True]) >> > > In this case, the `[1, 2, 3]` is being converted into an array of integers > before it is acted upon by `np.isfinite`. The function needs an array and > the list-to-array coercion selects a reasonably narrow dtype based on the > values in the list. In principle, the dtype of the list of Python `int` > values could be `object`, `np.int64`, `np.int32`, or maybe even a floating > point type (because integers are a subset of the reals), but `np.int64` is > reasonable. (Although on Windows, the choice is `np.int32`!) > This is a good answer to the original question, but just want to offer the small clarification that this changes in NumPy 2.0, the default integer on 64 bit windows is now int64. > When the `np.isfinite` function is given an array, which already has a > specified dtype, it takes that dtype seriously and doesn't try to change > it. So, given `np.array([1, 2, 3], dtype=object)`, no coercion is > attempted, and `np.isfinite` can't operate on arrays with that dtype. > > The difference with respect to Julia is that types are more of a focal > point of user attention than in Python. NumPy array types are a focal point > of user attention, but Python types are less so. `Any[]` is a good analogue > of NumPy arrays with `dtype=object` in the sense that functions don't try > to downcast them to the narrowest type supported by their values, but there > isn't a good Julia analogue of a Python list, which is fair game for such > downcasting. A Python user, like me, *wants* NumPy to figure out that if > I pass `[1, 2, 3]` to a function that needs an array, it should cast it as > an array of integers—at least when I'm in the hacking stage of developing a > project or interactively trying things out in a terminal or Jupyter. Later, > to have more control over a project that's getting more mature, I'll be > explicit about types and explicitly cast them as NumPy arrays with > specified dtypes. (For example, to ensure that integer types have the same > bit width on all platforms.) Since Julia uses types to determine which > implementation of a function to run, Julia can't be this loose about types > at any stage of development: invoking a different method-overload of a > function is not a small, gradual change. > > For the interface between Python and Julia, then, there are going to be > some hard decisions to make. Not every type on one side has a good > equivalent on the other. Personally, I would consider it reasonable for all > Julia AbstractArrays to transfer to Python as NumPy arrays—none of them as > Python lists. The transformation can't be bijective because Python lists > would transfer to Julia as `Any[]`. Users of both languages would have to > be aware that the conversion doesn't round-trip. > > -- Jim > > _______________________________________________ > 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: nathan12...@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: arch...@mail-archive.com
