
"Leland Brown" wrote
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
<...>
I'm still unclear about the exact semantics you are looking for.
I hope it's a little more clear after answering your questions above.
Yes. I can see the point of what you are saying now. The new type might be called a base_quantity or something like that. When using it you could guarantee that length is always in meters, time in seconds and so on. The advantages would be that it is much simpler to understand what is going on, as you don't need to think about unit conversions and so on. It might also be useful for use where you need to guarantee that no conversions are taking place, such as if you wished to switch in a quantity for dimension checking of your calculations and switch it out for release. However if you need to deal with other units it should be borne in mind that it would be inferior both in speed and accuracy to the current fixed_quantity aka t1_quantity. The speed is probably not as critical as the accuracy issue. (and BTW I am in the process of stripping out and replacing the horrendous compile time unit conversion code from quan::fixed_quantity. Here is the latest version in quan CVS at sourceforge concept_08_July_2006-branch, of the code (with comments!) for doing a multiply of two fixed_quantities where the reult is dimensioned: http://tinyurl.com/qvmaw . Now all I need to do is all the rest!). The base_quantity (basic_quantity?) would also need its own operations defined, as derivation from fixed_quantity would otherwise mean any math would return a fixed_quantity, so it would probably need to be a standalone type. Nevertheless I can see it would be useful. Another thing on th todo list... <...>
Yes, that's what I meant. Length is a property of the desk. But in order to express that length numerically, you need to specify the units. The numerical value is always tied to its units. The length may be expressed as 2 m, 200 cm, 2000 mm, or .002 km - but the length of the desk is the same. I just like to have a software abstraction that matches the physical abstraction of "length."
Yes I know exactly what you mean here!. Howver AFAICS now the requirement is for (at least) 4 abstractions: fixed_quantity, multiunit_quantity, universal_quantity and base_quantity :-) (BTW I would love to call these fixed_quan, multiunit_quan, uni_quan, and base_quan :-) . I guess maybe fixed_quantity name will have to remain as it is though now for stability :-( .)
A "length" object
would represent the desk's length in a similarly abstract way, which could then be expressed in whatever units are desired for I/O.
<snip>
Having used the fixed-quantity aka t1_quantity and multi_unit_quantity aka t2_quantity for a while, I have found them to be very flexible in the ways that they can be used. The fixed_quantity and all the different predefined quantities in the headers represent a compile time database of SI quantities and units and I have no doubt that this database will have a wide range of uses, but I will leave these up to the future user to explore as there is a lot of work involved in just getting the original library functionality completed satisfactorily.
I am currently (slowly) trying to write a roadmap for Quan library. I will put a message up here when I have put it up somewhere. Meanwhile here's the Quan Docs url again for those interested. (the docs there are Much older than CVS FWIW, which incidentally I found can be browsed with ViewCVS just like any normal html pages which is quite cool): http://quan.sourceforge.net/quan_matters/doc/html/index.html regards Andy Little