Andy Little wrote:
pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose)
There have been a couple of requests for this. (BTW meter is acceptable by the SI , but metre is not IIRC.) The longer names work ok for units such as meters, but:
length::millimeters
is quite a handful, while:
acceleration::millimeters_div_seconds_squared acc;
is a real handful compared with:
acceleration::mm_div_s2 acc;
Sure, this is a matter of taste. I think for the base units it should be fine, though.
pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have.
The use of 'div' is meant to stand in for 'divided by' as laid down in 'The Guide for the international System of Units' section 7.12.
I'm open to changing the rules by which these typedefs are formed, but I would prefer a consensus around one scheme, on grounds that two entities meaning the same thing is never a good idea, also bearing in mind that it needs to be useable over a wide range of various units as shown above.
I don't see why two entities with the same meaning is necessarily a problem. That's the whole point of typedefs. If the community agrees that one interface is best, I'm find with "div" due to the official SI recommendtation.
Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power?
Again if there is a consensus I will add it but I guess I figured that it was redundant. Does it aid comprehensibility? :
1 kg.m^+2.s^-2
If it does I am happy to use it.
Getting rid of the "+" would help: 1 kg.m^2.s^-2 Or better yet: 1 kg.m^2/s^2 But the latter will get you into all sorts of complexity wrt parentheses, etc.
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
But I don't understand why the SI "interface" commands a particular pqs implementation. From the user perspective, they don't really care. But as soon as a programmer tries to extend the framework, nightmares ensue. Perhaps I'm just not understanding something very fundamental and basic.
Even before pqs was put up for formal review, I had planned to make use of it in some computer simulator work that I'm doing. The ability to create units like Megabytes and Mibibytes would help tremendously. Unfortunately, I could not figure out how to create a unit that uses prefixes that are powers of 2. It might be ok to "fake" it if the calculations always stayed within one system (Mibibytes, Kibibytes, etc.) but as soon as one wants to convert Mibibytes to Megabytes it falls apart.
OK. Firstly I should point out that bytes and their units arent physical quantities and so according to my self imposed rules re PQS, I ( and the SI) dont cover them under physical quantities. Second as far as I know the binary prefixes arent intended to apply to physical quantities but are only for use in the so-called 'electrotechnology' field.:
http://physics.nist.gov/cuu/Units/binary.html
Unfortunately I dont know whether the relevent standards bodies have plans to change that or not.
I think restricting the library to "physical quantities" is a big mistake. You've put a _lot_ of effort into getting the metaprogramming right for his and we ought to try to re-use it wherever possible. I don't relish the idea of creating a parallel "electrotechnology system" framework that looks exactly like pqs but with powers of 2 and 10 (to do the conversions). Let's get it right in a single library.
However in its raw form , it is possible to use the library to model other entities than physical quantities. The assignment of a particular base dimension to one of the fields in the dimension is arbitrary really and you could use the core of the library for your own purposes. I should show an example of this type of use. The problem is that you need to add all your own functionality and that is the major work.
How would this added functionality interact with the power-of-10 framework? The big issue is converting between a system that uses powers-of-10 and some other system (powers-of-2 in my case).
Having said that I will look into how feasible it is to enable the use of alternate units. I could probably tighten the use of base 10 to the particular unit type and uses a traits scheme to allow other bases to be used.
That would be great. It will be necessary to allow conversions between powers-of-2 and powers-of-10.
As stated above, once out of the realm of physical quantities its up to you what you assign the base dimensions too. I would guess you would certainly need two base quantities, time and bytes to start with.
Right. And conversions.
I could provide the ability to customise the number of available dimension 'slots' via a macro. This might speed compilation for users that regularly only use length, mass, and time for example.
I was thinking along those lines as well. -Dave