Re: [boost] [PQS] Length::m vs Length

From: Leland Brown (lelandbrown_at_[hidden])
Date: 2006-07-11 01:48:36

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
> "Leland Brown"  wrote
> > Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
> >> "Beth Jacobson"  wrote
> >> > I agree that unit checking can be an extremely useful feature, I'm
> >> > just not convinced that tight coupling is necessary to achieve
> >> > that.
> >
> > But I also agree here.  The goal can be achieved without necessarily
> > making the units part of the type.

<snip>

> > A couple of people have suggested a syntax more like this:
> >
> >    length d = 5 * meter;
> >    speed v = 2 * inch / second;
> >    time t = d / v;
> >    cout << "time = " << t / minute << "minutes";
> >
> > I also like this usage - this is how my library works.  As you've
> > pointed out, Andy, this is trivial to achieve with the current PQS
> > implementation, by using:
> >
> >    typedef pqs::length::m length;
> >    typedef pqs::time::s time;
> >    typedef pqs::velocity::m_per_s speed;
> >
> >    const length meter(1);
> >    const length inch(0.0254);
> >    const time second(1);
> >    const time minute(60);
> >
> > The problem is, it also allows sloppy code like this:
> >
> >    length d(5);  // no error; but units not clearly documented!
> >    speed  v(2);  // no error; but units not clearly documented!
> >
> > so that the numeric values are now divorced from their units (which
> > are defined above, in the typedefs), thus potentially leading to
> > another Mars lander problem.
> 
> I should clarify here that the units are still there in the type although not
> visible in the source code

True.  I should have said, the units must still be part of the type, always.  
Here they're just not part of the type name, so that the user doesn't need to 
worry about units EXCEPT when needing a numeric value for a quantity, at which 
time you must decide what units you want for the numeric value.

> > What I want is the syntax I illustrated
> > but to enforce specifying units along with numeric values.

> The idea being so that you would say:
> 
>     length d = pqs::length::m(5);
>     rather than
>     length d(5);    //Now an error
> 
> ?

Exactly.

>      Would you want to allow this:
> 
>      length d = pqs::length::mm(5); // initialise to 5mm converted to meters
> 
> ?

Yes, "length" should be compatible with any length units, like that.

>     Then you would probably need this too:
> 
>     pqs::length::ft d1 = d;

Yes, I think so.

> OTOH   Should
> 
>      length d = pqs::length::mm(5);
> 
> be an error ?

No, it should be allowed, because 5 mm is a valid length.

> I can see that deriving from the current t1_quantity (now called
> fixed_quantity in Quan, the successor to PQS) could be beneficial for various
> uses.

<snip>
 
> Currently though my priority is to finish off the original concept. It seems
> to work quite well, as well as being as flexible as possible.

Yes, that makes sense.  My suggestion can easily be added as an extension 
later - it doesn't need to affect the current design.

> I'm still unclear about the exact semantics you are looking for.

I hope it's a little more clear after answering your questions above.

> > Here's an example of how I think about physical
> > quantities:  My desk has a length.  "Length in meters" or "length in
> > inches" are not properties of the desk - only length.  That length can
> > then be expressed numerically in different units.
> 
> I would prefer to say it can Only be expressed numerically if the units are
> known otherwise the number is meaningless. *Assuming* what the unit is, is
> where the  mistakes occur. The SI is pretty clear that a quantity must always
> have its units close by.

Yes, that's what I meant.  Length is a property of the desk.  But in order to 
express that length numerically, you need to specify the units.  The numerical 
value is always tied to its units.  The length may be expressed as 2 m, 200 cm, 
2000 mm, or .002 km - but the length of the desk is the same.  I just like to 
have a software abstraction that matches the physical abstraction of "length."

>  A "length" object
> > would represent the desk's length in a similarly abstract way, which
> > could then be expressed in whatever units are desired for I/O.

<snip>

> Having used the fixed-quantity aka t1_quantity and multi_unit_quantity aka
> t2_quantity for a while, I have found them to be very flexible in the ways
> that they can be used. The fixed_quantity and all the different predefined
> quantities in the headers represent a compile time database of SI quantities
> and units and I have no doubt that this database will have a wide range of
> uses, but I will leave these up to the future user to explore as there is a
> lot of work involved in just getting the original library functionality
> completed satisfactorily.

Yes, I'm sure there is!  That sounds like a good plan.

-- Leland