Re: [boost] Re: physical-quantities

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-08 11:10:52

> I think a good starting point for reducing compile time, and more  
> importantly, *code-writing time* would be to shorten those names.

I don't really know about compile time reduction - a smart compiler  
will undoubtedly use a hash of some sort to reduce names into integers  
or something more manageable...  As far as code-writing time goes, I  
guess I spend so much more time thinking about implementation and  
algorithms than actually typing code that the long names are not an  
issue.  I also have a personal preference for completely unambiguous  
naming and, in this case, most users won't see this verbose stuff as it  
is more internal to the library.  On the other hand, I'm not  
particularly strongly attached to this particular choice of names...

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> template<class Y>
> dimensioned_quantity<Y,dimensioned_unit<si_model,quantity_type> >
> idealGasLaw
> (dimensioned_quantity<Y,dimensioned_unit<si_model,pressure_ty pe> > P,
> dimensioned_quantity<Y,dimensioned_unit<si_model,volume_type> > V,
> dimensioned_quantity<Y,dimensioned_unit<si_model,temperature_type> > T)
> {
>     return (P*V/(8.314*(_joules/(_kelvin*_mole))*T));
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This snippet is carrying some baggage from an earlier version which was  
not specifically tied to the SI model; i.e. it was written to deal with  
arbitrary unit systems.  A more concise version with the existing  
library would be :

template<class Y>
typename SI<Y>::quantity
idealGasLaw(typename SI<Y>::pressure P,
             typename SI<Y>::volume V,
             typename SI<Y>::temperature T)
{
     return (P*V/(8.314*(_joules/(_kelvin*_mole))*T));
}

> Another question in my mind is what's the reason to have  
> "pressure_type", or "temperature_type"?  Are they actually doing any  
> work?

These are the actual lists of abstract dimensions - pressure_type is  
this typedef :

// l^-1 m t^-2
typedef
boost::mpl::list<dim<length_tag,static_rational<-1> >,
                  dim<mass_tag,static_rational<1> >,
                  dim<time_tag,static_rational<-2> > >         
pressure_type;

> Another question I have is about the purpose for "si_model" above.  
> Here in Canada we constantly mix metric and imperial units.  If one  
> was working on software that controls a rover on a distant planet, I  
> can see a good reason to restrict the units to a closed system; and I  
> wouldn't mind having the ability to set a compile time constant that  
> effects such restriction. But if I'm working on a circuit layout CAD  
> application, most lead-through components are dimensioned in mils  
> (inches/1000), while most surface-mount components are dimensioned in  
> millimeters.
> But most of all, I'd hate to have to type "si_model", "si_model",  
> "si_model", "si_model", "si_model",... many times a day.

The question of mixing units from different systems treads on the  
sticky ground of unit conversions and whether (and if so, when) they  
should be implicit or strictly explicit.  From a safety perspective, it  
seems that requiring explicit conversions is the most conservative, but  
opinions definitely differ widely on the point.  If you're willing to  
deal with unit conversions on initialization, you can just do things  
like :

SI<double>::length	lead_through_length(10.0*_mils),
                                surface_mount_length(4.0*_millimeters);

and have all the internal stuff done in SI.  I have thought about the  
possibility of doing away with unit models entirely - the only problem  
is then you need to define some absolute reference for conversions  
which can cause problems if you want a system which deals with the  
Planck length as a natural quantity (10^-33 m) and want to convert to  
attometers or something else small - if the common base is SI, you  
potentially end up with precision problems.

> template< typename Y >
> Y idealGasLaw( pascals<Y> p, litres<Y> v, kelvins<Y> t );
>
> ?
>
> Kelvins should _themselves_ 'know' that they are a temperature type.  
> And if I threw Celsius at it, it should know what to do, too.

This is a perfect opportunity for template typedefs; it would be great  
to just be able to do something like

template<class Y> typedef  
dimensioned_quantity<Y,dimensioned_unit<si_model,temperature_unit> >  
kelvin<Y>;

That would make me a happy person...  As far as Celsius goes, I am  
still ruminating on a way to deal with more complex unit conversions  
(affine rather than linear in this case, but potentially nonlinear for  
other unit types) without incurring unnecessary overhead where you  
don't need it.

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