Complex magnitudes and other non floats

[redhog]

PintArray does not currently support magnitudes of any other type than float. This includes complex numbers, so storing e.g. complex frequencies or I/Q values is not possible. Other compound types have the same problem: I started experimenting with storing coordinates with associated CRS (epsg codes) as pint values which works fine (including reprojection in context converters), but they can't go in a PintArray either :(

[MichaelTiemannOSC]

Xref #139

[redhog]

Ah thanks, that's very similar.

https://github.com/MichaelTiemannOSC/pint-pandas/commit/b5954fdc78f8e8dd386ee77206e59af44c90489c#diff-3181ac97c806b62303f85f408bb9a556bdf5f61171d45ccc87df59a3c3adf6a5R228

would have to change. Why is the casting there at all? Can't self._data be a numpy array with dtype O if need be?

[redhog]

I also think you have to fix https://github.com/MichaelTiemannOSC/pint-pandas/commit/b5954fdc78f8e8dd386ee77206e59af44c90489c#diff-3181ac97c806b62303f85f408bb9a556bdf5f61171d45ccc87df59a3c3adf6a5R337

[redhog]

I'm not super familiar with the pint pandas code, but could give making a PR a try if you want, unless you can just whip that up super easily?

[redhog]

My projections implementation and example code:

https://github.com/emerald-geomodelling/experimental-pint/blob/master/pint%20projections.ipynb

[MichaelTiemannOSC]

@redhog I couldn't follow your comments into the diff, but I'm happy to make whatever changes. I've very new to the pint communities and have no pride of authorship (yet).

[andrewgsavage]

Ideally, for a solution that works for all types, we'd want

• A different PintType for each numeric type, eg pintm, pintm. This will need caching with respect to the numeric type in addition to the unit, see https://github.com/hgrecco/pint-pandas/blob/master/pint_pandas/pint_array.py#L71
• A way to work around numeric types that don't store integers, like integers. Take a look at what pandas has done for integers: https://pandas.pydata.org/docs/user_guide/integer_na.html
• A way to ensure the correct numpy dtype is used wherever possible. I'm assuming we want to avoid using object dtype when possible for speed / memory. I believe there's people using this with large datasets.
• Test fixtures for any new numeric types supported.

PRs that help tackle these issues are welcomed!

[MichaelTiemannOSC]

I second Andrew's encouragement to (1) solve the NA problems, so we are not stuck resorting to float NaNs to represent NA data, and (2) to avoid object dtype, not only because of speed/memory efficiency, but once something becomes and object_dtype, it loses all the wonderful properties of Extension Arrays.

[redhog]

Made a PR that solves this that I think works, but it might break some assumptions I'm not aware of...