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

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-10 22:43:43

On 10/10/05, Jeff Garland <jeff_at_[hidden]> wrote:

> Expression rearrangement is really cool stuff, but it doesn't really
> impact
> the interface does it? If you're serious about putting it in boost it's
> really the interface and docs that will ultimately matter the most.
> Personally I'd like to see a units lib proposal sooner rather than
> later...
>
> Jeff

No, it doesn't impact the interface. You use operators just like you
normally would. However, I do feel the need to make expression rearrangement
toggleable even if the rearrangement is fully optimized to compile-time on
almost all compilers, since rearrangement of expressions could have subtle
effects on precision, or even cause things like overflow or underflow in
different places than in the unorganized expression. These types of things
generally shouldn't be an issue, but they cause enough concern to make a
mechanism to turn off the behavior if necessary. Right now I plan on adding
function templates which act as expression modifiers that turn on and off
reordering i.e. strictly_ordered( expression_here ) to make it such that the
internal expression isn't reordered, and loosely_ordered( expression_here )
to explicitly allow the internal expression to be reordered (which can be
nested inside strictly_ordered expression). Similar toggles would be made
for other optimizations through expression templates. Initially, I plan on
making all expressions loosely_ordered by default, but I may provide
additional point, vector, and scalar templates which default to strict
ordering when used in expressions if people would want such functionality.
As of now, I'd prefer not to add those additional point, vector, and scalar
templates, just to avoid unecessarily bloating in the library, but this
opinion may change if such templates would be commonly used.

Much of how I am developing the library is dependent on expression templates
and many impact optimization in ways some might not initially think about.
For instance, last week I realized that even simple assignment operations
benefit from the expression templates. As an example, take the expression

your_quantity = some_meters + some_feet;

Without expression templates, you pretty much arbitrarily choose whether to
convert meters to feet or feet to meters on the right side of the equals,
however since the operations are now expression templates, the choice can be
determined better by context. If your_quantity is a quantity in meters, then
some_feet should be converted to meters in the expression. If your_quantity
is in feet, then some_meters should be converted to feet in the expression.
Otherwise, the complexity of the conversion decides which unit_type should
be used. Such analysis of context to produce the more optimized choice is
entirely possible using expression templates.

On 10/10/05, Deane Yang <deane_yang_at_[hidden]> wrote:
>
> If you dig back in the archives, I tried to explain it all before, but
> obviously not very well. Suffice to say that a "time point" and a "point
> quantity" are the same type of thing and that the difference between any
> two such things is a "vector quantity" or equivalently a "time_duration".
>
> Mathematicians have identified the common abstract concepts underlying
> these things, and I went on and on about this earlier. But I think I'm
> going to resist reviving all that, because I don't think it's
> particularly helpful. I like Matt's terminology, because it seems to be
> more meaningful for everyone.

I wish I had seen that conversation when it was active. I'm glad that I'm
not just going crazy about these relationship, as no places I've found even
make mention of them.

--
-Matt Calabrese