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

From: J.F.K. (beholder_at_[hidden])
Date: 2003-11-20 22:28:34

Hello Matthias, Hello Andy

I am the one physicist who is VERY interested in such a 
library, but, sorry, I have no time to help you with this.
I can just read your messages in this thread, and I do it.

thanks for your advance,

Oleg.

----- Original Message ----- 
From: "Matthias Schabel" <boost_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Friday, November 21, 2003 7:58 AM
Subject: Re: new compile-time dimensional analysis and unit 
library

> 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