RFC: SI Units facility for Phobos

[BCS]

Hello Andrei,

> Benjamin Shropshire wrote an SI Units implementation which he refers
> to here:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=3725
> 
> For convenience, here are direct links to the code:
> 
> http://www.dsource.org/projects/scrapple/browser/trunk/units/si2.d
> http://www.dsource.org/projects/scrapple/browser/trunk/units/rational.
> d
> 
> This cannot be considered a reviewable proposal yet because it doesn't
> have sufficient documentation and is essentially in the stage where
> Benjamin is asking for input on improving the design and
> implementation.
> 
> Below are my comments in response to Benjamin's RFC. In brief, the
> design is a bit off from what I hope to have an a units library, but
> things can be fixed without too much difficulty by shuffling things
> around.
> 
> * Call the library std.units and generally focus on units, not on SI
> units.
> 
> * 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.

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

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

> 
> * There should be no implicit conversion to double and generally few
> conversion smarts. The units should have a writable public field
> "value".
> 
> * There should also be a property called siValue which yields the
> value, converted to SI, of type double. For an Angstroms, siValue
> returns value * 1e-10.
> 
> (Step-by-step on the code:)
> 
> * The code should use TypeTyple instead of T.
> 
> * I think FullSI should be always in effect. Even though many users
> don't care for lumens and moles, they can just sit there defaulted at
> the very end and shouldn't be bothersome.

That's my soap box protest to SI's (IMHO stupid) inclusion of them as base 
units. :)

> 
> * Each artifact (extra, extra2, Batch...) should be documented.

Um, Yah. :o)

> 
> * I'm not sure about the use of fractional exponents. They add a fair
> amount of complication. Could we dump them or use a simple fixed-point
> scheme to accommodate them?
> 

The only unit I know for sure has fractional exponents is in fracture mechanics 
(kPa*m^0.5) but if you allow anything beyond that, any fixed-point scheme 
I can think of would fall over right away (X^1/3?).

> * The naming convention should consistently use NamesLikeThis for
> types and namesLikeThis for values (including constants).
> 
> * A scheme similar to std.conv.to should serve as an all-around
> converter, e.g. to!Kilometers(Miles(10)) should yield a value of type
> Kilometers that contains 16.05 or whatever.
> 
> * All operators should be converted to D2 (yet another success story
> of the new design :o)).
> 
> * Packages of remarkable constants would be nice to have, of course in
> the appropriate units. The fields of astronomy, classical/relativistic
> mechanics, electromagnetism, molecular physics, quantum mechanics,
> come to mind.
> 
> All - please add your comments. Benjamin, I hope you're as
> enthusiastic as always about pushing this into Phobos!
> 

I am.

> Andrei
>