RFC: SI Units facility for Phobos

[Andrei Alexandrescu]

On 1/5/11 12:26 AM, BCS wrote:
>> * I suggest doing away with abstract unit names ("Distance", "Time",
>> "Mass" etc.) and use concrete plural units ("Meters", "Seconds",
>> "Kilograms" etc) instead. I agree that at a level operating with the
>> abstract names seems to be more pure, but at a concrete level you need
>> to have various reference points. For example, a molecular physics
>> program would want to operate with Angstroms, which should be a
>> distinct type from Meters.
>
> Why would that be an improvement? The current system encode as length
> measurements as meters but allows you to work with other units by
> converting at the point that you convert a FP type to a united type. The
> issue I see with making different units of length different types is
> that there is an unbounded set of those and I don't see any reasonable
> way to allow encoding the conversion structures for them.
>
> If someone else is able to make such a library that is as clean as this
> one, I'd not stand in its way, but I have no interest in writing such a
> beast.

It would be an improvement because there wouldn't be the need to 
multiply with a bias every time a value is assigned, with the 
corresponding loss in speed and precision.

To exemplify, say a program wants to work in Angstroms. As all distances 
are stored in meters, ultimately all values stored and operated on would 
be very small, which adversely affects precision. At the other end of 
the scale, an astronomy program would want to work with light-years, 
which would force storage of large values as meters.

To solve this issue, each unit may include a static multiplier that 
converts it to SI (e.g. meter), while at the same time allowing to store 
and operate directly on the unit of choice. So a program may actually 
store 10 Angstroms as the number 10, or 10 light-years as the number 10.

>> * There should be ways to define scalars of distinct types and
>> relationships between them. For example, "Radians" and "Degrees"
>> should be distinct types, although both are scalar.
>
> Ditto my comments for non-scalers on a smaller scale.

The crux of the matter is that Radians and Degrees should be distinct 
types, and that a conversion should be defined taking one to the other. 
How can we express that in the current library, or what could be added 
to it to make that possible?

>> * The previous points bring me to an important design artifact: each
>> and every unit should have a multiplier (constant, template argument)
>> that describes its relationship to the SI corresponding entity. The SI
>> units themselves will have a 1.0 multiplier, and e.g. Angstroms has a
>> 1e10 multiplier. The current library has a facility for that, but I
>> think that's not as good.
>
> That sounds to me like what the library has so I must not be
> understanding what you are asking for. Could you elaborate?

I think my comments above clarify this. If not please let me know. In 
brief: one should be able to operate on values that are implicitly 
scaled, which are of distinct types (Angstroms, LightYears, Radians, 
Degrees would be illustrative examples).

>> * In the proposed design the user can define a lot of distinct types,
>> such as Miles, Yards, and Lbs, which are strictly unnecessary
>> (Kilometers, Meters, and Kilograms could be used instead, with
>> appropriate I/O conversions to and from other units). I think offering
>> scale-less units chosen by the user is a good thing as long as there
>> is a unified mechanism for converting between those units without
>> risking confusion and bugs.
>
> Again, that sounds to me like what the library does. All distance units
> are of the same type and internally are encoded as meters, The rest of
> the units are converted on access.

The issue is that the choice of the unified format may be problematic.


Andrei