> My only caveat is that I don’t think tracking physical units should be a > primary use case. Units are fundamentally different than data types, even > though there are libraries out there that treat them more like data types. > > I strongly disagree. Right now, you need to implement a custom container to > handle units, which makes it exceedingly difficult to then properly interact > with other array_like objects, like dask, pandas, and xarray; handling units > is completely orthogonal to handling slicing operations, data access, etc. so > having to implement a container is overkill. Unit information describes > information about the type of each of the elements within an array, including > describing how operations between individual elements work. This sounds > exactly like a dtype to me.
Yes I see your point. > Finally, units may be different for each axis in multidimensional data. For > instance, we want a float32 array with two dimensions with the units on one > dimension being time and the other dimension being spatial. (3 seconds x 50 > nm). > > The units for an array describe the elements *within* the array, they would > have nothing to do with the dimensions. So for an array of image data, e.g. > brightness temperatures, you would have physical units (e.g. Kelvin). You > would have separate arrays of coordinates describing the spatial extent of > the data along the relevant dimensions--each of these arrays of coordinates > would have their own physical quantity information. Again, you are correct. I’m asking for similar metadata attached to the data shape rather than the data type.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
