RE: [boost] pqs - physical quantities library

From: Noah Stein (noah_at_[hidden])
Date: 2004-10-27 10:20:04

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Andy Little
> Sent: Friday, October 22, 2004 6:09 AM
> To: boost_at_[hidden]
> Subject: [boost] pqs - physical quantities library
> 
> Hi,
> 
> I have been continuing with my physical-quantities library over the last
> year,
> http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
> and I am now seeking feedback as to whether it is worth putting this
> forward
> as a boost library proposal....
> 

I've looked over your library a little.  Overall, I like it.  Having started
one a few years ago, I understand how much work has gone into it.  I have
some feedback:

* I would appreciate a little more depth in the glossary.  The definitions
are very much about the mechanics.  A "coherent-quantity" is a
concrete-quantity with an incoherent-multiplier of 1.  Does that mean a
kilometer is incoherent since its incoherent-multiplier must be different
than the meter?  Or is it coherent because it is part of the SI system, but
feet, miles, etc. are incoherent?  Looking through the code I believe the
latter to be true, but the documentation doesn't succinctly explain that.
In following links regarding coherent and incoherent quantities it felt like
circular definitions.

* Unless I missed it, I think you need to add a term to your nomenclature.
What's between an abstract and a concrete quantity?  length::m is an
abstract-quantity with quantity-unit but no value thus it's neither abstract
nor concrete.  I would guess that this kind of quantity will probably be
discussed a bit.
 
* I believe the system is too SI-centric, resulting in this point and the
two following. I would like to see the library move away from the SI units
taking 7 of 9 prime-unit slots.  I can envision a number of applications
that could benefit from a quantities library but aren't based heavily on SI
units.  For example, if I'm modeling the business side of a networking
company, my units could include computers, megabytes, and dollars.  So there
would be a lot of tracking of dimensions I don't care about and currently
not enough available dimensions currently to track what I do care about.

* The coherent prime-dimension-unit should be selectable.  I don't want any
precision issues beyond those that are strictly required.  I'd prefer to see
a system where I can specify a "coherency-set", e.g. S.I., Imperial, etc.
Each coherency-set should be completely encapsulated from other sets.  If I
need conversions from one set to another, I can specialize a conversion
template class for the two sets.

* I'm a little leery of the structure of of_length, etc.  It's not
extensible to adding new unit types.  To bring up a system I mentioned once
before in a different thread, how would I add length::cubit without mucking
around in the library files themselves?

* of_quantity seems a little limiting regarding conversion issues.  If my
underlying value type is a UDT (such as an arbitrary precision type), I
would like to have conversion numbers be objects of that UDT to maximize
precision.

* What's the plan for non-ICE pow()?  A compile-time solution is clearly not
an option.  For completeness, it would be nice to see an example of how to
deal with the situations where quantity information is lost.

Thanks,
Noah