Re: [boost] Re: physical-quantities

From: Phil Richards (news_at_[hidden])
Date: 2004-01-09 06:54:36

On Thu, 08 Jan 2004 13:44:19 -0700, Matthias Schabel wrote:
>> I'm not sure I understand the need for an absolute reference. Couldn't
>> each unit BE its own absolute reference? Inside meters, 1 m == 1;
>> inside mm, 1 mm == 1. Conversion functions could be non-class
>> functions:
> I like the suggestion - I've been thinking along these lines lately. The
> only problem with having a non-class conversion function is that there
> will be N^2 overloaded functions for N different units.  That makes
> extensibility a problem : for example, if the library itself defines a
> few length units (pseudocode alert)
[...]
> Maybe the
> solution would be to have a default converter which looks something like
> 
> template<typename model1,typename model2>
> convert<length_unit<model1>,length_unit<model2> >
> which uses SI as a common base and if the unit doesn't support
> conversion to/from SI, then the user would have to write the conversion
> function themselves...  I'll have to think about this more...

You've pretty much got the support you need already: the toBase() method
in each UnitInfo.

You can define the "convert<>" function above in term to do (something
like - clearly this needs to fit into your template framework...)
   return model1::toBase() / model2::toBase();

This is what I did in my (still not posted) version:

template<typename ValueType, typename Dimensionality,
    typename NewUnitSystem, typename OldUnitSystem>
struct convert_units_helper
{
  static ValueType scaling_factor()
  {
    return
      (unit<Dimensionality, OldUnitSystem>::template scale<ValueType>()
      / unit<Dimensionality, NewUnitSystem>::template scale<ValueType>());
  }
};

(unit<> is similar to your UnitInfo, "::scale<>" is like "::toBase<>" -
not exactly the same, but similar.)

The clean thing about this approach is that if you have 2 "small world"
systems, then scaling_factor() will evaluate (say):
 1e-30 / 1e-27
So the scaling_factor applied to the *actual* value will be 1e-3 - which
is generally pretty accurate.

phil
-- 
change name before "@" to "phil" for email