Re: [boost] new compile-time dimensional analysis and unit library

From: Matthias Schabel (boost_at_[hidden])
Date: 2003-11-20 20:58:20

        From: 	  Matthias Schabel <matthias_at_[hidden]>
        Subject: 	Re: [boost] Re: new compile-time dimensional analysis and  
unit library
        Date: 	November 20, 2003 6:57:19 PM MST
        To: 	  Boost mailing list <boost_at_[hidden]>

> As I said later in last post . Its pretty trivial to add explicit.
> In the above context this is a policy.
> BTW I use explicit on initialisation by value.,
> but I would argue that is structurally necessary to prevent pq falling
> apart. If not:
> pq_velocity<>::m_per_s v1(1),v2(2);
> pq_force<>::N                f  =  v1 /  v2;                    // no  
> error

Of course, I would say that this is an argument for retaining  
dimensionless
types as distinct and _without_ implicit conversion.  In that case, the  
result
of dividing two velocities would be dimensionless and could be used, but
only with explicit conversion.  The "experts" tend to also view implicit
conversions as dangerous :

http://www.gotw.ca/gotw/019.htm
Meyers, More Effective C++ pg. 24-31

> If its contentious I would be strongly in favour
> of a switch for make unit conversion explicit yes or no.
> Of course it would have to extend from no, else it would break my code.
> Start off less restrictive and then impose the policy.

On the other hand, if you're building a library, it's much easier to  
start out
with a more restrictive interface and wait to see if the users actually  
experience
enough problems with said restrictions to justify broadening it...   
That is, if
the initial release disallows implicit conversion, it can always be  
added later
without breaking code conforming to the initial release - the opposite  
isn't
true...

> Yes I see your point.. well sort of. My immediate thought on  
> implementing
> arrays/vectors would
> be just as a a vector of pqs... presumably the above has advantages  
> over
> that scheme ?

Efficiency - the units can exist on top of existing data vectors as a  
reference-
containing wrapper, sparing the cost of copying _many_ data elements  
while
at the same time enabling unit correctness :

// double *in,*out; -> large vector/matrix which has been allocated  
elsewhere

SI<double>::Mass	M(in); // -> constructs using reference for non-POD  
types
SI<double>::Energy E(out);

function_using_units(M,E); // does dimension checking with no runtime  
cost

Otherwise you'd have to copy data back and forth (or use nasty  
type-casting
tricks)...

> BTW  boost::array<double,5>   does that work ?

http://www.boost.org/libs/array/index.htm

> Incidentally one( real or imagined) problem with use of a lot of MPL is
> compile time.
> its a dirty word but has to be taken into account in a practical  
> system.
> if it takes too long to compile,as a user I wont use it -  end of  
> story.

Unless you're writing a program which uses a tremendous number of
fundamentally different unit types, each type and the associated code
should only be instantiated once, so compile time should be relatively
irrelevant.  Of course, the codes I'm working with involve 3D data sets
of up to 256^3 voxels and similar sized PDE solvers, so the compilation
time is negligible compared to runtime...

> Overall I hope you would agree that some documentation would help
> to convey the ideas behind your library. (I am working on that for  
> mine but
> takes time !)

Agreed - anyway, if we're the only two on this list who are interested  
in such
a beast, which I'm starting to suspect from the general lack of other  
comment,
it may not be worth expending a tremendous amount of energy in  
documentation...

> My current view is that we should keep the two ideas separate  
> initially, do
> more work and see how each works in practise.

Certainly - I think we need outside comment to ascertain which solution  
is most
appealing.

> basically no direct relationship betwen angle and pq.
> Let the programmer decide

There are many cases of equations which are expressed in terms of some  
physical
quantity per radian or steradian - even though these are not properly  
dimensioned
quantities (being, in fact, dimensionless types expressed as  
length/length or length^2/
length^2) .

Cheers,
Matthias

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