"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050129141037.DE6D0E305@derisoft.derived-software.demon.co.uk...
On 2005-01-28, Robert Ramey <ramey@rrsd.com> wrote:
The fact that units is required and important shouldn't inhibit the utility of a dimensional analysis library. Ideally, a units library would depend on a dimensional analysis library. But a dimensional analysis library should be able to stand on its own.
Indeed it does. I use one every day... we don't care about unit conversions because we don't do any.
I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
We also don't care about anything but 4 of the dimensions, so that's all we use. (We could use more - it is just an mpl::vector of fractional powers.)
With pqs I was trying to create a concrete type. IOW I was very preoccupied with making a simple user-interface. I go back to the example of std::string. (which is an interface). Whatever its faults I dont want in general to create my own allocators or char types every time use it. So though I accept the idea of customising the number of *base-units* [1] , for a widely useable set of physical quantities types a default the 7 in the S.I. system are required. The *unused* base-units increase compile times and lengthen the signature for error messages, but because of its universality this is worth it. I opted not to use a mpl::vector, rather each base-unit is given its own type, which is more understandable in error messages. Again this is due to a concern with the user-interface.
Still, as I said, agreement couldn't be achieved last time round on pretty much anything,
This seems to be a pessimistic view of what went on IMO. Is it not up to the librray designed to come up with a solution based on the discussions. I incorporated some things from these discussions into pqs. However I have always had a very specific view of what I want from a physical_quantities library, which has naturally had a major influence on the design. Some things that came up were * Fractional dimensional-exponents. * What is the result type from a calculation of dimennsionally-equivalent types but of different units. * How do you distinguish dimensionally equivalent but different quantities. * Angles (One not dealt with yet is centigrade) Another frequent point was "money as a physical quantity". Money is not a physical quantity, Nevertheless there is a place for another type, built on the building blocks of currency and physical quantities: area::m2 wall_area(length * height); apply<divides,currency::dollars,area::m2>::type cost_per_sq_m ; // <-- here in >> cost_per_sq_m; currency::dollars cost =cost_per_sq_m * wall_area; However this presupposes the currency and physical quantities libraries For all these things A universal operator type deduction mechanism is required, while waiting for decltype. BOOST_DECLTYPE may provide the interface but there needs to be an underlying framework too. May still be reqd after decltype too.
and life is too short to discuss whether angle should, or shouldn't, be able to be treated as a dimension that sometimes is, or isn't, dimensionless...
Though if there was to be a boost version, unfortunately this would need to be thrashed out. And that is the problem. It is a big project. I would ideally like to 'boostify' pqs but dont have time currently. However Robert Rameys idea to do the dimensional anlysis library alone seems good, as it is less contentious and surely would not be too much work Still requires generic operator result_type deduction though, whether based on mpl, result_of, BOOST_DECLTYPE, lambda lib,spirit or whatever... [1] ( FWIW The term dimensions is incorrectly used here. According to S.I. the correct terminology is dimension of the systems base units)