$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andy Little (andy_at_[hidden])
Date: 2006-06-07 16:40:33
"David Greene" wrote
> Andy Little wrote:
>> David Greene 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.
The problem is to get something that works well for all units, is easy to
remember, has a consistent formula and is concise. When I am writing source
code, I am not worried about whether a quantity is a base unit or not. I need to
be able to figure out its name quickly and write it quickly too.
>>> 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.
IMO if you have two names for something its because the first was a mistake for
some reason.
>>>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
Again, if its preferred enough then I'll modify it. I should point out that
ideally you wont get these format output anyway, because you assign everything
to a so called named_quantity, FWIW, which should have prettier custom output.
In practise its unlikely you will be serialising anonymous quantities. ( because
you are usually not serialising temporaries) IOW anonymous quantities are a bit
ugly, the output format reflects that.
> Or better yet:
>
> 1 kg.m^2/s^2
>
> But the latter will get you into all sorts of complexity wrt
> parentheses, etc.
Yep!. The dots work quite well as separators and again the format is based on
the recommended useage in the SI manual which uses dots.
>> 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.
I dont think electrotechnology is an extension to the SI. IMO its a different
system in which bytes and time exists, but not mass, length, current etc etc.
regards
Andy Little