Re: [boost] [Review] Quantitative Units library review begins today, March 26

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-03-30 07:10:45

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of John Phillips
>Sent: 26 March 2007 12:55
>To: boost_at_[hidden]
>Cc: boost-users_at_[hidden]
>Subject: [boost] [Review] Quantitative Units library review 

>   The review for the Quantitative Units library, submitted by 
>Matthias Schabel and Steven Watanabe.

• 	What is your evaluation of the design?

Correctly, IMO, emphasises compile-time checking (with next to no run-time cost) over run-time conversions. (Run-time is
superficially attractive but loss of precision creates plenty of pits for the novice to fall into, not to mention the run-time cost.
Slow and dirty?).

Handles non-integral power dimensions well enough.

Correctly IMO does not try to handle input-output (except very simple output).
(Its takeup with will be increased by more examples of doing this - even though individual requirements will vary widely, examples
of 'fiddling with facets' will be a great help.

Capable of handling a wide variety of different unit systems, including astronomical units.

Correctly, IMO, "this library is designed to emphasize safety above convenience".

Default is to enforce explicit conversion - but makes it possible for implicit conversion if the user wants to take the risk - a
reasonable compromise.

Inter-operation with other Boost libraries like serialization and interval is a good sign.

Handles the deceptively complex temperature conversions effectively.

• 	What is your evaluation of the implementation?

Effective. 

Sufficiently portable - older compilers cannot ever provide a solution to this problem.

Been developed and supported over a long enough time to give confidence of future support and development.

Fast enough with current hardware and compiler software to make the added security against mistakes worth the cost of increased
compile time.
(Nobody has used it on an industrial strength (size) project to say if this is a startup cost that does not increase compile time so
much for big projects - but I too believe this will prove to be so.)

• 	What is your evaluation of the documentation?

Boost quality - and that's a compliment, not damning with faint praise ;-) - but of course it can always be improved - and I trust
will be in the light of user experience.  A very useful set of examples, but the very many responses to users questions could very
usefully be added as additional examples of very many more applications, like currency and other conversions etc.  A lot of naïve
users will be using this library (I hope) and they will need all the help they can get.

• 	What is your evaluation of the potential usefulness of the  library?

Very widely useful - if more trouble than some will wish to get started.
(I see no way of reducing the learning curve steepness and hassle factor in use in the language C++ - it is already using state of
the art MPL and will work better with C++0X 'typeof'.  And, AFAIK, it achieves far more than any other language in both units and
dimension checking.)

Although serious scientists and engineers are the obvious customers, very many programming tasks involve some measurements, often
done by programmers whose experience is mainly in more integral objects.  So I see the potential for *very* wide application.

And because its primary objective is compile-time checking, with considerable complexity, and some compiling-time cost, some may
decide not to use it.
This is not a reason not to include it as a Boost library.

• 	Did you try to use the library? Yes, briefly, with VS 2007 compiler.
  Did  you have any problems? No. 

• 	How much effort did you put into your evaluation?

Re-study of the documentation after following the (very!) long Boosters debates.
Brief test of a few examples.

• 	Are you knowledgeable about the problem domain?

Slightly.  But I have followed all the discussion and proposals on this topic.

• 	Do you think the library should be accepted as a Boost library? 

Yes - definitely.  We have waited far too long for a 'perfect' solution to these difficult problems: it does not exist. The Best is
the Enemy of the Good.

It seems obvious that we can't please all the people all the time,
but this design and implementation makes a good compromise between conflicting potential users, potential use domains, and offers
enough extension potential to other more esoteric and frankly bizarre unit systems, if at the cost of making even expert programmers
brains hurt a bit.  

Although I was in favour of accepting Andy Little's PQS into Boost, I remained uneasy about it for reasons I could not fully
articulate:
I am much more comfortable with the balance of pros and cons of this submission.

We now need some real users to use this code in 'real anger': if it survives this, it will be truly proven.  We won't, IMO, get
much, if any, large-scale use until it is accepted into Boost.

Paul

PS Nit noted en passant:

Quick start spelling mistakes: "of using user-defined types in dimensional calcuations,"  and  /// test calcuation of work 

- should be calculation, twice.  One of my favorite spilling misfakes ;-)

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]