-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Friday, October 22, 2004 6:09 AM To: boost@lists.boost.org 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