Re: [boost] formal review request : mcs::units

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-02-07 05:11:41

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Matthias Schabel
>Sent: 06 February 2007 23:25
>To: boost_at_[hidden]
>Subject: Re: [boost] formal review request : mcs::units
>
>> I would suggest that you have a
>> pod_quantity for defining the various
>> constants so that they can be safely
>> used during the dynamic initilization
>> phase.
>
>I'm not sure I follow you here...could you elucidate
>a little more? At this point, I'm not sure whether the constants
>are appropriate for inclusion in the library or as an example -
>what I would prefer to do is to encapsulate them in something
>like the measurement class so that the errors are also
>accessible, but I'm worried that trying to include such a class
>would start to get out of the scope of the core library itself.
>In particular, I think that a measurement-like class that does
>standard propagation of errors would also be critical for any
>Boost numerical methods library (GSL provides a result type
>that encapsulates value/error pairs) and could share an
>implementation...

I agree that feature-creep is looming and that Matthias is right to resist.

However, it will be comforting to show that there one can sketch out prototypes to show 'proof of concept'.  Failure to template can
cause frustration later when this blocks extension.

It can also highlight potential pitfalls.

Steven's suggestion of a pod_quantity is an example.  

template<class Unit, class T = double>
struct pod_quantity {
    //like quantity but without constructors/assignment operators
    T val_;
};

pod_quantity<si::velocity> c = { 299792458 };

at first sight appears to work OK with T a value + uncertainty type - but of course one cannot then rely on its initialisation
because it's not longer pod and needs a constructor.

However this is really a language problem - one that is recognized and really should be solved in C++0X.

So let's get walking before we try to run.

Paul

PS Please can we use the word 'uncertainty' rather than the obselete 'error'.
Errors can be corrected, but uncertainty only reduced ;-)

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