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

From: Andy Little (andy_at_[hidden])
Date: 2006-07-11 08:58:21

"Leland Brown" wrote
> Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

<...>

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

Yes. I can see the point of what you are saying now. The new type might be
called a base_quantity or something like that.
When using it you could guarantee that length is always in meters, time in
seconds and so on.

The advantages would be that it is much simpler to understand what is going on,
as you don't need to think about unit conversions and so on.
It might also be useful  for use where you need to guarantee that no conversions
are taking place, such as if you wished to switch in a quantity for dimension
checking of your calculations and switch it out for release. However if you need
to deal with other units it should be borne in mind that it would be inferior
both in speed and accuracy to the current fixed_quantity aka t1_quantity. The
speed is probably not as critical as the accuracy issue. (and BTW I am in the
process of stripping out and replacing the horrendous compile time unit
conversion code from quan::fixed_quantity. Here is the latest version in quan
CVS at sourceforge concept_08_July_2006-branch, of the code (with comments!) for
doing a multiply of two fixed_quantities where the reult is dimensioned:
http://tinyurl.com/qvmaw . Now all I need to do is all the rest!).

The base_quantity (basic_quantity?)  would also need its own operations defined,
as derivation from fixed_quantity would otherwise mean any math would return a
fixed_quantity, so it would probably need to be a standalone type. Nevertheless
I can see it would be useful. Another thing on th todo list...

<...>

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

Yes I know exactly what you mean here!. Howver AFAICS now the requirement is for
(at least) 4 abstractions:
fixed_quantity, multiunit_quantity, universal_quantity and base_quantity :-)

(BTW I would love to call these fixed_quan, multiunit_quan, uni_quan, and
base_quan :-) . I guess maybe fixed_quantity name will have to remain as it is
though now for stability :-( .)

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

I am currently (slowly) trying to write a roadmap for Quan library. I will put a
message up here when I have put it up somewhere. Meanwhile here's the Quan Docs
url again for those interested. (the docs there are Much older than CVS FWIW,
which incidentally I found can be browsed with ViewCVS just like any normal html
pages which is quite cool):

http://quan.sourceforge.net/quan_matters/doc/html/index.html

regards
Andy Little