Dimension: a method to make the protocol distinguishable

[lucascolley]

We would like to add a method to the protocol to help statically distinguish it from other classes. One suggestion so far is

@property
def is_dimensionless(self) -> bool: ...

[nstarman]

Agreed. Making the Protocol distinguishable is crucial!

[nstarman]

How about an alias field with other common names for the dimension?
Ping @mhvk since Astropy does something similar.

[mhvk]

Confused about the context: is percent dimensionless (it is, but scaled); is radian (in SI, yes).

And, yes, there is no one-to-one mapping from unit to dimension, which I think is to me the real feature of Dimension, that it allows us to express whether we mean a pressure or an energy density.

[lucascolley]

Confused about the context: is percent dimensionless (it is, but scaled)

Yes, perhaps we clarify in the docstring that dimensionless means 'just' dimensionless (not also scale-less)

is radian (in SI, yes).

Yep, I don't see any problems here. u.dimension.is_dimensionless() will in general depend on the system of u, but we don't need to specify certain Dimensions tied to systems to support that.

[nstarman]

We also don't need an is_dimensionless method specifically. The Issue is about making Dimension be a meaningful Protocol.

For example:

class AnyObject(Protocol): ...

is not a good protocol object because it matches every object. While

class Dimension:
    aliases: list[str]  # other names, e.g. length and distance, time and duration
    def __metrology_namespace__(self, ...): ...
    def to_formula(self, DimensionSystem) -> dict[str, float]:
        # given the system defining the fundamental dimensions,  return the representation
        # in terms of the those dimensions e.g. {"length": 1.5, "time": -1}

would be quite specific to Dimension and not Unit.

[mhvk]

@lucascolley - nice, if is_dimensionless() is dependent on settings, like whether to treat angles as dimensionless, it makes much more sense to have it!

[lucascolley]

if is_dimensionless() is dependent on settings, like whether to treat angles as dimensionless

To be clear, my thought was that the same Dimension object will either be always "dimensionless" or always not "dimensionless", regardless of context or settings (I don't think this would be enforced by the spec at all, but it would be the simplest case).

If u1 represents a Radian unit in an SI system, then we can expect u1.dimension to return some d1 such that d1.is_dimensionless() == True. If u2 represents a Radian unit in a system which has a plane-angle dimension, then we can expect u2.dimension to return some d2 such that d2.is_dimensionless() == False. But d2 and d1 could be completely unrelated (apart from both being a Dimension).

[mhvk]

OK, that also makes sense, but to me that then makes a bit unclear what the point of is_dimensionless() actually is.

Note that in astropy we have the concept of equivalencies, where u.dimensionless_angles() is used very often (for small-angle conversions mostly).

[lucascolley]

what the point of is_dimensionless() actually is

Yes, in implementations the more idiomatic thing would probably be to check d1 == the_dimensionless_object, assuming that there is just one dimensionless Dimension. That does suggest that we might want to consider something like Nathaniel's proposed to_formula instead.

[nstarman]

The name was a quick example. decompose() might be better name for the method. And perhaps the keys should be Dimension objects, not str

[mhvk]

That sounds reasonable. We should not let the Protocol force us to make a method with a super unique name, though. Perhaps that is an argument for __dimension_namespace__ after all? With the suggestion that, generally, all those namespaces point to the same thing? The problem is really that we are proscribing some behaviour, not particular methods.