EuroSciPy 2025 Maintainer Track: Standardised Quantity/Unit APIs discussion

[lucascolley]

Just to let everyone know that my proposal for the maintainer track session in the title was accepted for EuroSciPy this year—would be great if anyone can attend!

[neutrinoceros]

Do you know if the conference will be accessible remotely ?

[lucascolley]

As far as I know, it won't be. But I suppose nothing to stop us from setting up a video meeting for the session??

[lucascolley]

Reminder that this is coming up next week! https://euroscipy.org/talks/NHKMDP/

If anyone has topics / blockers that they think would be useful to discuss, or would like to try to join any discussion remotely / contribute resources beforehand, please ping here!

No expectations, I imagine it will be rather informal. But happy to make the most of it if people are keen to make progress!

@quantity-dev/members

[mhvk]

Thursday Aug 21, 16h CEST, right? Are you thinking of setting up a video meeting?

[lucascolley]

Thursday Aug 21, 16h CEST, right?

👍

Are you thinking of setting up a video meeting?

If there is interest!

[andrewgsavage]

How did this go?

[lucascolley]

we had a good discussion with about 15 people! You can watch the recording at https://www.youtube.com/live/bht7d78VmU8?si=C3UrZH-Mx7k-LRTc.

There was quite a bit of thought (and confusion) about how exactly unit conversion should work, but the sentiment (including some discussion after the session) was that the suggestion of mn.converter in quantity-dev/metrology-apis#6 (comment) seemed good.

One takeaway from the confusion there is that we need to be clear that in practice, the Value (and thus Quantity?) parameter of the namespace returned by Unit.__metrology_namespace__ will typically be quite specific. In order to define converters between e.g. logarithmically related units, it will be necessary to have some knowledge about how to perform logarithmic transformations on the values. I think this sort of thing can and should be addressed as part of quantity-dev/metrology-apis#17.

The main takeaway was that the API feels ready to be adopted into quantity-array. I'm hesitant to work on that yet though, without a concrete implementation which it could consume. I wonder whether you have any plans @mhvk @nstarman to start investigating an implementation for Astropy Units 2.0? If not, then I think our main focus should be on those with the typing know-how helping you @andrewgsavage push quantity-dev/metrology-apis#12 forwards.

[andrewgsavage]

thanks, listening to that:

• we could really use a document explaining design decisions as you'd skipped past those and people asked design questions. eg Why are you using a namespace, why asquantity...
• some graphs/graphics explaining how the metrology api interacts with array api or other use cases

You were focusing on the array api/scipy uses cases. There are lot more than just that, many of which are are simpler as they don't involve arithmetic or arrays. eg I had spent a morning last week trying to work out where I'd gone wrong in a heat transfer calc because I wasn't using units because cantera doesn't (yet) have a pint wrapper. With an common api they'd be able to support any unit module.

+1 on your next steps

[lucascolley]

You were focusing on the array api/scipy uses cases. There are lot more than just that, many of which are are simpler as they don't involve arithmetic or arrays. eg I had spent a morning last week trying to work out where I'd gone wrong in a heat transfer calc because I wasn't using units because cantera doesn't (yet) have a pint wrapper. With a common api they'd be able to support any unit module.

Yes of course! For context this was off the back of quite a few array API related discussions on that day and the previous day, so it made sense to introduce it from that angle (also given my involvement with quantity-array). But the most interesting use cases may have nothing to do with arrays indeed.