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

From: Andy Little (andy_at_[hidden])
Date: 2006-06-04 04:59:45

"Pavel Vozenilek" wrote
> _______________________________________________
>>> 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).

I could change the name from pqs to si_units in reference to Walter Browns
library.

http://physics.nist.gov/Pubs/guidelines/TN1297/tn1297s.pdf

That would also reinforce the SI foundations of the library.

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

Its a tricky problem.  colours denote electro-magnetic radiation within certain
frequency ranges of the spectrum.

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

Quickbook is convenient and as the docs are large I am tempted to stick with it
as there is a lot of docs to do. It is certainly an improvement in productivity
over HTML anyway. There are probably ways to customise Quickbook/Docbook that I
dont know about too, but the downside usually is that flexibility goes.

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

I can add this as a link for C.G.S system but my point is that its informal
rather than official.  AFAIK C.G.S has been swallowed up by the SI system.

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

You mean that :

 #include <boost/pqs/types/length.hpp>

 should bring in the (socalled) t1_quantity, t2_quantity for length?.

Its worth thinking about, though I do have certain doubts about putting
everything in one header. It would make life simpler though. The current
hierarchy is noticeably too deep.

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

The Wiki reference I turned up:

http://en.wikipedia.org/wiki/Acre

suggests that this refers to components of an area.I am sure its an error, so I
will have to look into how its turned up there.

As you said previously there should of course be tests to check the validity of
the named_quantities and their typedefs and constants too. Tests ned work like
everything else.

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

A change of name from 'incoherent unit' to 'historical unit' is an attractive
suggestion. I could change the term 'coherent unit' to 'SI unit' then. That
might clarify things.

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

I could remove all the named_quantities part of the library and leave it to the
user to deal with which sounds like what you are suggesting. That would
certainly save me a lot of work. However from my own point of view ( as a user)
I am quite lazy and I like all this work to be done for me. I feel that the
current interface works reasonably well. A point that is remarkable about the
current library is that basically its a large database of value_types rather
than something to compose ones own types from.  In fact the format of the naming
convention for the named_quantity typedef  isnt well documented, but the
ambition was that the interface (ie length::m) communicates better than the
class template t1_quantity<length,zero_unit,double> does.

Apologies that I find it difficult to communicate what I am trying to say here.
I feel that the interface ( which you want to be able to customise) is the most
important part of the library in many ways. That is its most useful feature and
is what saves the user time and effort, assuming they understand the 'feel' of
it of course. The interface hides some rather messy details of the t1_quantity,
( coherent/incoherent units etc etc) . Remove the
interface and the user is exposed to all that which is not good AFAICS. They
then need to recreate their own interface.

(Maybe I'm too attached to the current interface!)

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

My conceptual problem with that is that it waters down the strong type checking.
Taking your following example.
These units only make sense as lengths. They cant be applied to forces or
velocities. That is why its an implementation detail currently. Its really just
an extended floating point type.

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

Use of physical quantities to represent screen coordinates I am quite keen on
(whether modelled using PQS library or just by a set_units("millimeters")
function. This is one area that pqs cant fulfill on its own and finds it
difficult to mix different types of units, because some of these units are
outside the realm of physical quantities. A screen pixel is device ( or device
mode) dependent, whereas a millimeter is absolute. I cant remember the details
but some specs (maybe SVG) use a weird hybrid where a printer point is 1.5
screen units on a certain screen resolution or some such monstrosity.  pqs can
only deal with the absolute type of units.

Thanks again for your review and feedback on the library.

regards
Andy Little