Re: [boost] [Review][PQS] Physical Quantities System review(May31through June 9)

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-06-03 20:32:46

 _______________________________________________
>> 1. The name "pqs" should be changed to
>>   something a little bit more descriptive.
>>
>>   "unit" feels quite handy.
>
> Thanks for the suggestion. I am OK with changing the namespace to unit if 
> it
> makes more sense to do so.
>
Whether unit or something else - psq would be maintenance
headache (TLAs should not be used, there are enough of
domain specific ones).

 ______________________________________________
>> 2. intro.html: I find some terms as "t1_quantity"
>>   rather annoying. What they mean? How do these
>>   names help novice to understand the library
>>   better?
>
> The latest I could come up with has been chico_quantity,
> harpo_quantity and groucho_quantity.
>
That's too US centric. If a property of quark is referred
as red/blue/green then C++ library may as well.

> This is one downside of using Quickbook. By default It tends to
> impose a sequential style ( with the prev/ next arrows), whereas in my
> hyperlinked documents I prefer to use a 'star' and or hierarchical system 
> with
> the index as the hub and directories.
>
Quickbook is not mandatory. The best documentation
currently in Boost is not limited by it, for better.

>>   C.G.S. is not linked.
>
> There doesnt seem to be an authority that maintains it. Its kind of a 
> historical
> curiosity AFAIK.
>
Searching for this I found quite large
collection of units:
http://www.sizes.com/units/index.htm
(http://www.sizes.com/units/sys_cgs_em.htm few CGS specific)

>>   Path names as
>>     #include <boost/pqs/t1_quantity/types/length.hpp>
>>
>>   - I am against showing history related details (t1, t2, ..)
>>   to the user. One wants to used the library w/o
>>   hassle, not to deal with "t1".
>
> I dont follow what you are saying here. Do you mean that I should use more
> meaningful variable names?
>
 I mean that
    #include <boost/pqs/types/length.hpp>
should really cover current and future
length metrics.

The "t1"s would be hard to maintain in legacy code

>> The "acre" here is length or breadth?
>
> hmm. That should be an area. I'm not sure how that got there. There is an
> area::acre too.  Looks like a problem in my header generator.
>
I though so but found (in Wikipedia) that two historical
length units of this name exist.

 _______________________________________________
>> 14. typeof_register.hpp: the warning against
>>    Typeof changes after admitting to Boost
>>    should be updated/removed.
>
> OK. Hopefully Typeof will be out soon :-)
>
I believe it will available in 1.34, at least it
is in current CVS.

>>    And when I am at it: when one uses nF and mF
>>    mistake is easy to happen and hard to spot.
>>
>>    I would love to have typedefs with names
>>    like nano_farad and micro_farad available as well.
>>    The cost of typing is smaller than searching for
>>    a bug caused by wrong unit.
>
> Thats worth thinking about, but I would be concerned about the 
> duplication. I
> prefer one interface typedef. I'm not sure about that.
>
It would be even more usefulf for historical, ahem,
incoherent units. These could be used when
a statement from old manuscript gets encoded.
Here the wordiness would be especially handy.

Another target group could be students/amateurs/those
who forgot most of details long ago.

 _______________________________________________
>> 25. Naming: people may not like long names
>>    like boost:pqs:xyz.
>>
>>    Perhaps there could be a macro that,
>>    given a namespace (i.e. global) and common
>>    name prefix, will create all typedefs
>>    where the user likes them. Something as
>>
>>    BOOST_UNITS_DECLARE_ALL_IN(::, unit_)
>>
>>    and then "unit_m" would be meters.
>
> Maybe. but user can use namespace alias , typedef or using for preferred 
> set of
> units. Unless the current mechanism is unacceptable I am in favour of not
> providing alternatives.
>
The macro could be generated. Hand-typing the typedefs
would not be the best past-time. There is also chance
that someone may want to replace existing a legacy
unit typedefs with the new library.

 _______________________________________________
>> 26. The library provides dimensionless
>>    units (if I understanding it correctly).
>
> Its not intended too. Its intended that units are only applied to 
> dimension-ful
> quantities, (except for angles)
>
>>    For many applications these would be the
>>    most useful ones. There should be page
>>    dedicated only to this functionality,
>>    not bothering a read with Farads and inches.
>
> As it stands this is part of the implementation in
> <boost/pqs/detail/united_value/> . It may be worth making it a public part 
> of
> the library, though I hadnt thought about that before.
>

I am quite curious about it. I once wrote a mini-library
that provided ability to define types representing dimensionless
quantities and transformation between them.
It was possible specify which assignements are valid
and conversion was automatic. It was very simplistic
and the code is lost somewhere, though.

Example of use could be GUI units: pixels of screen,
pixels on printer, inches for physical representation.

/Pavel