RFC: SI Units facility for Phobos

[BCS]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> 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.
> >
> 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.

Ah. I see what you are getting at. OTOH I'm still not convinced it's any better.

A quick check shows that 1 light years = 9.4605284 ¡Ñ 10^25 angstroms. A mere 25 orders of magnitude differences, where IEEE754 doubles have a range of 307 orders of magnitude. As to the issue of where to do the conversions: I suspect that the majority of computation will be between unit carrying types (particularly if the library is used the way I'm intending it to be) and as such, I expect that both performance and precision will benefit from having a unified internal representation. 

There /might/ be reason to have a very limited set of scaling factors (e.g. atomic scale, human scale, astro scale) and define each of the other units from one of them. but then you run into issues of what to do when you do computations that involve more than one (for example, computing the resolution of an X-ray telescope involves all three scales).

When I started writing the library, I looked at these issue just enough that I knew sorting it wasn't going to be a fun project. So, rather than hash out these issue my self, I copied as much as I could from the best units handling tool I know of: MathCAD. As best I can tell, it uses the same setup I am.

> >> * 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?
>

I don't think there /is/ a good solution to that problem because many of the computations that result in radians naturally give scalar values (arc-length/radius). As a result, the type system has no way to determine what the correct type for the expression is without the user forcing a cast or the like.

If angles are treated as an alias for scalar then the conversion to degrees can be handled in a reasonable way (but that would also allow converting any scalar value to degrees). I again punted on this one because people who have put more time than I have available (MathCAD again) couldn't come up with anything better.

> >> * 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.

The issue I see is that the choice of a non unified format will be problematic. Unless you can show examples (e.i. benchmarks, etc.) of where the current solution has precision or performance problems or where it's expressive power is inadequate, I will remain reluctant to change it.