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

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-20 14:34:58

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:

> 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...

Actually, that's exactly what I said but in different words. Again, though,
read my other reply to understand why you wouldn't ever have to do this (the
one refering to type traits).

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:

> 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.

Why do you think repeated transformations occur with implicit conversion? In
fact, with automatic expression rearrangement, the amount of transformations
can be minimized even more-so. Remember, if you WANT to force conversions,
there's nothing stopping you from explicitly casting where you choose, it's
just that you aren't forced to do so since there is no logical reason why
the operation can't do it automatically. However, the expression templates
can potentially do just as good of a job as you, and often can do even
better since they may have more information about the individual objects in
a complex expression (i.e. concerning parameters to function template
instantations, where the best order of conversion can change depending on
the unit types of the objects passed).

Objects of length dimension represent the same concept even though the unit
details may vary. Forcing explicit conversions also forces those
implementation details to high-level code. Having automatic conversions
while supplying explicit casts operations keeps details hidden by default,
as they should be, and also allows for low-level toggling where it is
necessary. I don't see why you would want to always explictly cast, and the
"problems" in the examples provided, again, occur if the objects were of the
same unit type as well. The problems described were because a higher level
of abstraction was missed in the user's code, which isn't even solved by
always forcing explicit conversions, it is just hidden in a subset of some
of those cases where the two types just happen to be using different units
of the same dimension.

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:

> 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 :-)

...because the library does it automatically and provides a more concise way
of representing the expression in code. Forcing the user to be explicit only
requires more code and doesn't add anything. You can be explicit where you
want to be, but usually you're just being redundant since the library
figures out the best way to handle the conversions anyway.

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:

> 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.

Added complexity for me to write as the library programmer means less
complexity for the user of the library. Sure it's more complex to for me to
code in the library how to automatically figure out the best order of
conversions and how to properly organize an expression to produce the best
code, but so what? Me doing it once now solves it for everyone else later,
and since it's done programmatically at compile-time, it produces just as
good, and often better results than if a user were to do it explicitly, and
it has no runtime overhead. It's win-win with just a small sacrifice of a
week or two of my time.

--
-Matt Calabrese