Re: [boost] Interest in dimension/unit-checking library?

From: Phil Richards (news_at_[hidden])
Date: 2005-10-20 13:11:21

On 2005-10-20, Matt Calabrese <rivorus_at_[hidden]> wrote:
>  On 10/20/05, Phil Richards <news_at_[hidden]> wrote:
> > What I mean be overridden is: Could I choose to use velocity, force, and
> > pressure as the basis for my dimensional analysis (so rather than
> > thinking of velocity as "length / time", length would be represented as
> > "pressure^-1 force^1 velocity^-2")
>  You can do that as well by just creating your own "velocity" base
>  classification separate from the one I define. This would be rather silly
>  though as well as pointless. Currently you wouldn't be able to convert your
>  base classification to the more natural derived classification implicitly.
>  This could easily be added, but I don't think it is necessary.

Actually, it would be ill-formed - you would have introduced a mechanism
for allowing two things of the same dimensionality to be represented in
two different ways.  I'm really not convinced that this is good for
dimensional analysis...

>  Well, implicit conversions is how it will be at least for this version since
>  it's already all in place. I still don't see why you would want to force all
>  explicit conversions. Quantities in meters, centimeters, feet, inches,
>  miles, etc. all represent the same concept and should be able to be
>  converted between behind the scenes. Nothing logically bad ever comes from
>  it at that level of abstraction.

Repeated transformation of values is not something that I've ever found
particularly good when doing numerical algorithms.  It is generally
better to encourage up-front conversion and do everything internally
in a consistent set of units.  And explicit conversion forces you to
think about what operations are going on.  If I saw an equation written
using mixed units I'd run a mile - I'd wonder why the person hadn't
normalised all the values first :-)  In fact, if I was implementing it,
I would normalise the values first - using explicit conversions to make
it absolutely clear what was going...

>  At this moment, the only result I see from adding direct support for
>  quantities all requiring explicit conversions to the library is uneccessary
>  bloating since the restrictions you desire are better expressible with
>  higher-level code than a quantities library should provide.

Erm, there is little difference in forcing explicit or implicit unit
conversions in terms of coding.  I would, off-the-top-of-my-head,
expect implicit unit conversion to be ever so slightly messier to do
right - as demonstrated by you expresssion rearrangement example.
Anyway, I'll agree to disagree with you on this one.

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