Re: [boost] [Review][PQS] Review deadline

From: John Phillips (phillips_at_[hidden])
Date: 2006-06-14 11:24:53

Andy Little wrote:
> 
> 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?

   It means that for the sake of computation, it carries no units and no 
dimensions. So, if I wanted to talk about a velocity of a particle that 
is moving at 70% of the speed of light, and I make the scale choice that 
the speed of light is 1, then the velocity is v = 0.7. There are no 
units to include.
   I agree with your point below that we need to be a little more 
careful about the meanings of some of the words we are using. I 
apologize for my tendancy to use words the way I would with other 
physicists without defining them for what is largely a non-physicist 
audience.

> 
> 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.
> 
> ...(snip)
> 
> 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?

   Pi, and e and all the various others mean exactly the same things 
they have always meant, and have exactly the same values. All I'm doing 
is defining relationships between dimensions and selecting scales to 
measure those dimensions. No matter what scale I choose for the 
measurement, the ratio of the circumference of a circle to the diameter 
doesn't change. The values of things like pi and e are in some sense 
that I think we should avoid trying to describe in detail on this list 
more fundamental than any unit system.

> 
> ...(snip)
 >
> 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 ). 

   So, a refinement of the system described in a few TMP sources. OK, 
that's what I thought it would be.

> 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.

   I'm going to have to think more to make any useful comments about how 
it could be implemented, but thank you for the description.

> 
> 
>>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.

   So, if I divide 1 eV by 1 s, will the answer of that computation 
automagically be in Watts (Energy / time = power)? Put a different way, 
are all calculations on that 1 eV carried out by first converting it to 
Joules, and then acting on the value in Joules?
   I again need to apologize for the sloppy language, but this is what I 
mean by converting to SI units. I am not concerned about your handling 
of SI prefixes (which I think is fine) nor do I wish to force people to 
explicitly select the prefix when two quantities that have prefixes but 
are already in SI units are used in a computation (though some people 
would probably like to be able to force a certain prefix under some 
conditions). I'm more worried about things like conversions between 
pounds and Newtons, or between rods and fathoms, where there is more to 
do than keep track of a power of 10.

> 
> 
>>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.

   I agree that what I'm asking for is non-trivial. And I can't promise 
that the increased use that would come from this expansion will justify 
your added time. I'm simply looking at it from the point of view of 
"what should it do to be the solution for my problems in my work" and 
adding in some of what I know is done by others in the physical sciences.

> 
> 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

   And thanks for your willingness to discuss them.
   I know that you put hours and sweat into this library, and everyone 
prefers to be told how well they did instead of get into long 
discussions of what could or should be changed, so I'm sure there are 
times when this discussion gets tiresome for you. Thanks for continuing 
to be an active part of the conversation and giving your insight as 
someone who has actually done the work to implement some of these ideas.

                        John Phillips

> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>