RFC: SI Units facility for Phobos

[BCS]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> On 1/5/11 4:06 PM, BCS wrote:
> > In conclusion (yes I know this normally goes at the bottom) I think
> > we are wanting different and contradictorily things from this
> > library.
> I almost didn't read the rest thinking that that's all you inserted. 
> All: there's more, scroll down!

Oops. :o|

> One additional practical matter:
> > The way I would like that code to look would be:
> >
> > void computeFiringSolution(Radians angle)
> > {
> >      auto s = angle.sin(); // only exist for Radians (and Scaler)
> >      ...
> >      auto newAngle = std.units.arcsin(s);  // returns Radians
> >      static assert(is(typeof(newAngle) : Radians));
> > }
> This is nice in theory but would have you essentially wrap by hand an 
> unbounded number of functions. And for what? So they write angle.sin() 
> instead of sin(angle.value).

There are very few general functions I know of that take units other than scalers. As a result, I would expect that allowing scalers to implicitly convert to floating point would cover most of those. And for the rest (sin, etc.) there are few enough that adding them to the type may be practical.

For the non-general functions that do take non scaler values, I would think explicitly asking for the value as a given unit (as the library currently does) would be the better choice rather than having to convert it to the related type for the unit and then asking for the values:

FnTakingMeters(Meter(length).value);  // that could be redundant if length is already meters...
FnTakingMeters(length.value);  // but are you sure length it's already meters?

vs.

FnTakingMeters(length.meter); // gives length in meters.

> I appreciate the additional theoretical 
> safety, but I don't see how that benefit compensates the cost. I want a 
> practical library that allows me to work with libraries designed outside 
> of it.

I agree on what but I'm not sure on how.

> Anyway, let's not forget that at the end of the day my opinion is one 
> opinion and my vote is one vote. For the record, my vote is against the 
> library in its current form for the following reasons:
> (a) Poor documentation

Um, Yeah. :o)

> (b) Limited expressiveness

In which way? Adding arbitrary base units? Things like Dynamic conversion rates? 

> (c) Numeric issues as I described (and no amount of rhetoric will set 
> that straight; FWIW given the obvious question of scaling you need to 
> prove it works, not me to prove it doesn't)
> (d) Unrealized potential (if we approve this, backward compatibility 
> will prevent more comprehensive libraries having the same aim but a 
> different design). This argument is to be taken with a grain of salt as 
> in general it can be easily abused. What I'm saying is that once this 
> library is in we may as well forget about scaled units a la boost units 
> (which are the kind I'd want to use).

We have both said our piece on these, what do others think? I'd be particularly interested in what Don has to say on the numeric issues. Does an extra layer or two of FP rounding really mater.