Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-06-14 06:21:35


"John Phillips" wrote
> Andy Little wrote:

>> I conjecture that as one moves to other more esoteric unit systems then
>> things
>> are less well understood, even by physicists and mathematicians, and that
>> would
>> make working on a units library designed to encompass those systems much more
>> difficult. Is not much of maths and physics a search to find models of those
>> systems?
>
> Actually, I think your understanding of the pieces for generic unit
> systems is better than you realize.
> From a physicists point of view, there are just a few choices that
> need to be made to create a unit system.
> First is a choice of dimensions. What types of things are you going
> to measure, and how do they relate to each other. For example, the SI
> system chooses to measure length, time and mass as independent
> dimensions. This gives compound units for things like force, velocity
> and acceleration.

>[...] Relativistic units make the choice that velocities
> should be unitless, so to make that happen, the units for length and
> time must be the same. This is not what our daily intuition would have
> us expect, but it is consistent with the theoretic decription that
> unifies length and time.

I'm unclear what you mean by velocity being unitless. Do you mean that velocity
is treated as a dimensionless or numeric type in the relativistic system?

BTW I think I detect 2 definitions of unitless at various points in the PQS
review. I think one definition that has been used is that a unitless type is a
dimensionless or numeric type, while the other sees a unitless type as a
dimensioned type which has the *default* units for that system. For example in
the SI system a meter is 'unitless' according to this 2nd definition, whereas
pi is unitless according to the first definition.

It occurs that it is quite important to try to define these terms as precisely
as possible. I spent some time in trying to achieve that in PQS, in the
definition of terms section, but looking back and especially under the gaze of
serious physicists, mathematicians, engineers (and maybe even physicians :-) ),
that my attempt has been very amateurish, however these (non C++) definitions
are absolutely essential for clarity in a discussion of this sort, so if anyone
has suggestions on sources for these sorts of terms that would be helpful.
Although the definition of terms section in PQS is poor (because, looking back,
my terminology is extremely ad-hoc), nevertheless I am sure that trying to nail
down precise definitions of terms has been essential in getting PQS as far as it
has. In order to proceed though I should ideally spend some time in research and
then provide authoratitive references etc to justify my use of particular terms.
That should give them weight and authority.

 Energy units (The system used in almost all
> particle physics.) goes further and decides that everything should be
> measured in different powers of energy.
> Once the dimensional choices are made, choices of preferred scale
> need to be made. SI units differ from cgs units and even Imperial units
> mostly because different scale choices were made. The scale choice for
> Relativistic units is that the speed of light should be exactly 1, and
> everything other than that should be SI based. In Energy units, the
> scale choice is an amount of energy called an Electron Volt (The amount
> of energy it takes to move one electron across a potential difference of
> one volt.). In this system, both the speed of light and plank's constant
> are exactly 1.

OK . This seems to confirm your use of the term 'unitless' as equivalent to
dimensionless or numeric. If the speed of light is a numeric type in the
relativistic system it leads me to wonder what math constants such as pi would
mean (if anything) in this system?

(hmmm. Should I have asked that question? Pehaps I should just have shut up?
Have I opened Pandoras box for myself ? ;-) )

> To my understanding of what you have written, it already supports one
> specific choice of dimensional quantities (The choice made by the SI
> units.), and I think it could support other choices with minimal effort,
> since the choices can be phrased in terms of those made by the SI
> system.

Maybe. Essentially the C++ representation of the dimension part of the quantity
consists in an array (
such as mpl vector) of numbers representing a sequence of powers of the base
dimensions. (Assume for example a system which only has the base dimension
length; Then the dimension length itself would have power of 1, area power of 2
and so on ). The representation is acceptable if I only need to deal with one
system, but if I am required to convert between systems, I need to add to the
type representing a quantity, some mechanism to tell me which system my quantity
is a member of . As it happens I already have the so-called abstract-quantity,
which encapsulates the dimension of a quantity together with a tag so that
dimensionally-equivalent quantities can be distinguished for output purposes.
The abstract-quantity could be extended to include information regarding the
unit system, or the abstract-quantity could be an SI-abstract-quantity (IOW in
C++ concept terms the si_abstract_quantity would be a model of AbstractQuantity.
I could look into how this would work. There are always costs involved though as
I said in a previous post. The main problem is that it increases the size of the
ball-park quite considerably to put it mildly. I would be wary of adding the
functionality without adding some implementation because if I do that I can
(almost) guarantee it wont fit when someone tries to implement it, and then it
will tend to hang around as a sort of useless tail which no one can get rid of.

>Given that choice of dimensional quantities, it supports scaling
> between different unit systems. At the moment, I think it does that
> scaling automagically when the values are compiled and does actual
> computations in SI units (Please correct me if this understanding is
> wrong.).

It must be wrong currently, simply because I make the assumption in PQS that
there is only one unit system (the SI system), so there is no mechanism in the
type to distinguish between unit-systems. (This assumes we are using the term
unit-system to refer to a very similar entity of course, which we may not be).

Actually I think I am dealing with another unit system.. the natural unit
system. I have assumed that it uses the same dimensions as the SI system. I have
therefore expressed quantities in natural units in terms of their scaling to SI
units. An energy quantity expressed in electron volts for example would be
expressed as an energy unit which
if it had the numeric value 1 would be equivalent to 1.602177e-19 joules. The
conversion factor is encoded in a compile time entity representing the unit.

> I would prefer for unit conversions to only happen when
> explicitly requested, and for mixed unit expressions without requested
> conversions that match the units to produce errors.

First. the definition of what is a unit conversion is problematic. It probably
needs further explanation. However some unit conversions in PQS t1_quantity are
entirely lossless due to the use of logarithmic notation to express powers of
10. For example the result type of 1mm / 1 millisecond technically involves a
conversion, however the conversion is entirely lossless in both runtime speed
and accuracy because the calculation is actual a compile time subtraction of -3
from -3 leaving the result in units equivalent to meters per second. This
process is very similar to the way one would proceed in a manual calculation.
Requiring the programmer to convert millimeters to meters and milliseconds to
seconds before the calculation is cruel and any good programmer will feel the
ugliness of it!

> So, there are a few differences between more generic systems and what
> you have done, but if I understand what you have done so far, they are
> not as big as you seem to think they are.

OK. My concern is that I can add the theoretical ability for PQS to encompass
unit-systems other than the SI, but the only way to see if it actually works is
to write a reasonable sized implementation for a reasonable number of systems.
What you are asking for is I know very well a non trivial expansion of the scope
of the project! My solution to this is not even to attempt to go there. My goal
is simply to cover the SI system and let others extend the project to more
generic systems.

BTW Thanks for all your comments and input, and I'm sorry that I keep sounding
so negative but I have good reasons for being sceptical, some of which I hope I
have explained .

regards
Andy Little


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