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,
----- Original Message -----
From: "Matthias Schabel" <boost_at_[hidden]>
Sent: Friday, November 21, 2003 7:58 AM
Subject: Re: new compile-time dimensional analysis and unit
> 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
> types as distinct and _without_ implicit conversion. In that case, the
> 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 :
> 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
> 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
> > 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
> containing wrapper, sparing the cost of copying _many_ data elements
> at the same time enabling unit correctness :
> // double *in,*out; -> large vector/matrix which has been allocated
> SI<double>::Mass M(in); // -> constructs using reference for non-POD
> SI<double>::Energy E(out);
> function_using_units(M,E); // does dimension checking with no runtime
> Otherwise you'd have to copy data back and forth (or use nasty
> > BTW boost::array<double,5> does that work ?
> > 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
> it may not be worth expending a tremendous amount of energy in
> > 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
> > 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
> quantity per radian or steradian - even though these are not properly
> quantities (being, in fact, dimensionless types expressed as
> length/length or length^2/
> length^2) .
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk