Re: [boost] Re: physical-quantities

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-08 15:44:19

> AFAIK, names are lenghtened, not shortened;  only eventually being  
> resolved to addresses, etc. Hash tables and the like are used for  
> look-up's, but a full name is still required for equality comparison;  
> and so that doesn't cure the problem of compile-time memory use, which  
> bears on efficiency of use of hardware cache.

In either case, I don't really mind shortening things like  
dimensioned_quantity to dq and dimensioned unit to du as they're  
internal types which are only really of interest to library developers  
and possibly people designing their own unit systems, but not to the  
end user of the units part of the library.

> I'm not sure I understand the need for an absolute reference. Couldn't  
> each unit BE its own absolute reference? Inside meters, 1 m == 1;  
> inside mm, 1 mm == 1. Conversion functions could be non-class  
> functions:

I like the suggestion - I've been thinking along these lines lately.   
The only problem with having a non-class conversion function is that  
there will be N^2 overloaded functions for N different units.  That  
makes extensibility a problem : for example, if the library itself  
defines a few length units (pseudocode alert)

typedef length_unit<SI> meter;
typedef length_unit<CGS> centimeter;
typedef length_unit<English> foot;

and the N(N-1) conversion functions :

convert<meter,centimeter>
convert<meter,foot>
convert<centimeter,foot>
convert<centimeter,meter>
convert<foot,meter>
convert<foot,centimeter>

then if someone decides they want to use rods, they're going to have to  
add 4*3-3*2 = 6 new functions.  Then the next person who needs fathoms  
will have to add the 2(N-1) = 8 more functions, etc...  Maybe the  
solution would be to have a default converter which looks something  
like

template<typename model1,typename model2>
convert<length_unit<model1>,length_unit<model2> >

which uses SI as a common base and if the unit doesn't support  
conversion to/from SI, then the user would have to write the conversion  
function themselves...  I'll have to think about this more...

> Assume we forget about systems, there's not even a need for Celsius to  
> know that they are temperatures, as long as they are interconvertible  
> with Kelvins. Just my $.015.

I like this line of thinking.  I was never really comfortable with the  
idea of having models precisely because the extensibility is  
compromised...

------------------------------------------------------------------------ 
---------------------------
Matthias Schabel, Ph.D.                           	
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT  84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu