Boost logo

Boost :

From: David Greene (greened_at_[hidden])
Date: 2006-06-07 15:09:16


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk