Tests

[andrewgsavage]

adds some relevant tests copied from pint's numpy tests. probably adds some that aren't using pint-array too.

FAILED tests/test_array.py::TestNumpyArrayCreation::test_empty_like - AssertionError: assert False
FAILED tests/test_array.py::TestNumpyArrayCreation::test_full_like - AssertionError: Comparing <Quantity(
FAILED tests/test_array.py::TestNumpyArrayManipulation::test_transpose - AssertionError: Comparing array([[1, 3],
FAILED tests/test_array.py::TestNumpyArrayManipulation::test_concat_stack - pint.errors.DimensionalityError: Cannot convert from 'meter' ([length]) to 'dimensionless' (dimensionless)
FAILED tests/test_array.py::TestNumpyArrayManipulation::test_concat_stack - pint.errors.DimensionalityError: Cannot convert from 'meter' ([length]) to 'dimensionless' (dimensionless)
FAILED tests/test_array.py::TestNumpyArrayManipulation::test_broadcast_arrays - pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'nanometer'
FAILED tests/test_array.py::TestNumpyMathematicalFunctions::test_prod_numpy_func - AssertionError: Comparing <Quantity(
FAILED tests/test_array.py::TestNumpyMathematicalFunctions::test_power - Failed: DID NOT RAISE <class 'pint.errors.DimensionalityError'>
FAILED tests/test_array.py::TestNumpyUnclassified::test_max_with_initial_arg - pint.errors.DimensionalityError: Cannot convert from 'meter' to 'dimensionless'
FAILED tests/test_array.py::TestNumpyUnclassified::test_min_with_initial_arg - pint.errors.DimensionalityError: Cannot convert from 'meter' to 'dimensionless'
FAILED tests/test_array.py::TestNumpyUnclassified::test_meshgrid_numpy_func - AttributeError: 'numpy.ndarray' object has no attribute 'm'
FAILED tests/test_array.py::TestNumpyUnclassified::test_where - pint.errors.DimensionalityError: Cannot convert from 'dimensionless' (dimensionless) to 'meter' ([length])

[lucascolley]

thanks for working on this @andrewgsavage !!

[lucascolley]

this is a place where we will differ from the existing pint + NumPy behaviour. Any function which returns an array in the spec (e.g. https://data-apis.org/array-api/2023.12/API_specification/generated/array_api.empty_like.html#empty-like) will return a Quantity here.

So in most cases we will return a dimensionless quantity instead. But I know you already mentioned that the behaviour of the *_like functions should probably change to match the units of the input.

[lucascolley]

in the spec, the fill_value argument must be a python scalar, not an array - https://data-apis.org/array-api/2023.12/API_specification/generated/array_api.full_like.html#full-like

[andrewgsavage]

self.Q_(0, self.ureg.degC) is a scalar

[andrewgsavage]

the implementation may need changing - I was trying to get the relevant tests running first

[lucascolley]

it's a Quantity (scalar + unit), right? Which in terms of the standard is a 0-dimensional array, as opposed to a python scalar. Whether or not the standard is correct here has been questioned at data-apis/array-api-strict#55.

[lucascolley]

the failure for pow is just due to the current implementation being incorrect

[andrewgsavage]

I've nothing more to add to this, it's ready for merging

[lucascolley]

thanks. I'd like to switch this from using NumPy to using array-api-strict and get everything passing first

[lucascolley]

it looks like this will need some tweaking before we are thoroughly testing pxp arrays rather than np arrays, since list * unit gives a NumPy array.

[andrewgsavage]

is there a way to say left/right shift operations aren't supported so shouldn't be tested by array-api-tests?

[lucascolley]

You can edit xp-tests-xfails.txt. What is the problem though? Are they not well-defined for dimensionless quantities?

[andrewgsavage]

they're not something you'd want to do a quantity no, they haven't been implemented in pint for np arrays

[lucascolley]

they're not something you'd want to do a quantity no

Okay, that's fine for now, but long term I'm not convinced it is the right solution to stray from the standard for dimensionless arrays. It would be ideal if the result of asarray with no units specified worked like a normal array. I guess we can see in time how much of a problem it causes in downstream libraries, and reconsider if it is something they need.

[andrewgsavage]

alright, is there anything else that needs doing before this can be merged?

[lucascolley]

I need to review it! But yes, I'll skim the diff and see if there is anything obvious.

[lucascolley]

I looked through the changes in the implementation

[lucascolley]

for a follow-up PR, we should make use a leading underscore consistent everywhere

[andrewgsavage]

do you have a reference for needing to return the same array type? indicies and bools aren't quantities so dimensionless quantities doesn't make sense.
pandas EAs are required to return ints or bools for these operations
How do arrays that don't store ints/bools deal with this?

[lucascolley]

do you have a reference for needing to return the same array type? indicies and bools aren't quantities so dimensionless quantities doesn't make sense.
pandas EAs are required to return ints or bools for these operations

Hmm, there may not be a requirement for this in the standard, now that I take a look. I think we do assume it in SciPy though. At least in tests, we check that input namespaces are equal to output namespace, so that machinery might need to be made smarter to work with a wrapping library which can return arrays of the underlying namespace instead.

Happy to roll with your way for now and see if we hit any problems.

[lucascolley]

How do arrays that don't store ints/bools deal with this?

bool, int32 and int64 are required dtypes in the standard. There has been discussion on relaxing this and figuring out how to deal with missing dtypes, mainly because Apple's MLX library does not have double precision dtypes. But nothing has come of that yet. I can't foresee there being any accommodation for missing boolean dtype though. And there probably needs to be at least one integer dtype.

[lucascolley]

thanks again for working on this @andrewgsavage ! I pushed some tweaks, and will merge soon.

I'll make some more tweaks, like changing the project name to quantity-array, then look at setting up continuous deployment, and making a first release.