Unit API

[lucascolley]

Ideas for a minimal standard Unit API.

[nstarman]

1. Unit(Protocol) object.
2. with __mul__ and __div__
3. and __pow__
4. unit conversion something...

[andrewgsavage]

5. .dimensionality and some way to detect dimensionless
6. __eq__?

[phlptp]

Some other things we define __repr__ basically some way to convert to a string
__invert__ as 1/unit should probably generate a Quantity so there needs to be some way to generate an inverse unit.

[nstarman]

.dimensionality

Would that be on Quantity or on Unit, accessible on the Quantity by something like q.unit.dimensions ?

[andrewgsavage]

Pint provides both Unit.dimensionality and Quantity.dimemsionality.
I think it's commonly used enough to warrant being on Quantity

[nstarman]

Do we need a Dimension API?

[andrewgsavage]

Yes, I'd like Unit.dimensionality to return a Dimensionality object so I can check it is the desired dimensionality. There are quite a few issues relating to dimensionality in pint so I think it is used often.

[ngoldbaum]

unyt also uses dimensionality heavily

[SimonHeybrock]

• Serialization could be very useful.
• Distinguishing __str__ from __repr__ might make sense. For example, for a human-readable string vs. spelling out the underlying scale factor and powers of dimensions.
• __eq__
• Getting the scale factor.

[lucascolley]

Do we want to standardise a way for users to access/construct units other than via the Unit constructor? I know pint uses registries, and astropy has units accessible in the astropy.units namespace.

[ngoldbaum]

unyt has both a default unit registry that populates the units in the main namespace and also allows users to define custom unit registries.

It's very common in modeling and simulation to go back and forth between a "code" unit system and a "real" physical unit system, so having a way for units to be convertible between different unit registries is very useful.

That said, if all you want to standardize on is e.g. SI units, there's no need to include registries IMO. I personally find Pint's API that forces users to deal with registries to be needlessly complicated.

[lucascolley]

@andrewgsavage any thoughts?

[andrewgsavage]

The concept of registries in pint is that you can't convert between them as they may not share units/may have conflicting units / different factors

To have a "code" system and "real" system I'd expect people to use systems in pint (ie in the same registry)

I wouldn't standardise on a registry as I'd expect them to differ slightly.
pint's default registry has hundreds of units in, making it more difficult to find its non-unit attributes through autocomplete, so the units may get moved to registry.units

[lucascolley]

@ngoldbaum feel free to let me know if you would like an invitation to the org, btw

[ngoldbaum]

The concept of registries in pint is that you can't convert between them as they may not share units/may have conflicting units / different factors

In unyt the registries and unit systems are tightly coupled - each unit system has a registry. So I think this works out to more or less the same thing.

feel free to let me know if you would like an invitation to the org

That's alright, just keep me in mind as a person who has thought about this a lot from the perspective of trying to extract results with physicals units from 3D simulations that do wacky with units like adjusting the length scale with time, as in comoving units in a cosmological simulation.

[andrewgsavage]

It seems this discussion has run its course. What's the next steps here? Start creating protocols similar to https://github.com/nstarman/units/tree/main/src/units/api based on the discussion here?

[nstarman]

Now that we've had a bit of discussion, I think we should move on to a design document synthesizing the results of the discussion and sending out polls voting on non-resolved aspects, e.g. should the attribute be called .dimension or .dimensions. Also, I would suggest actually starting with the Quantity API. IMO it's easier to design "down" than "up". And since isinstance(x, QuantityProtocol) only checks the existence of attributes/methods, not their types, it's easy to have placeholder protocols for Unit, etc that get filled in when we move on to the Units API. WDYT?

[lucascolley]

Reading wikipedia, I get the impression that "dimension" is the standard property of a quantity. Do you have a preference for .dimensionality over .dimension @andrewgsavage ?

[ngoldbaum]

FWIW, unyt uses dimensions, and it's an attribute of the unit object:

>>> from unyt import km
>>> [1, 2, 3]*km
unyt_array([1, 2, 3], 'km')
>>> ([1, 2, 3]*km).units
km
>>> ([1, 2, 3]*km).units.dimensions
(length)

That said I'm not really sure why I wanted them to be plural when I came up with this API in 2014 or so.