Boost logo

Boost :

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.


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at