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

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-21 12:53:01

On 10/21/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> But wouldn't it make sense to develop a core dimensions/units library
> without any predefined dimensions in it and develop the SI quantities
> library as a layer above that?

That's exactly what my library is. It's a general physical quantities
library with SI just also provided as a set of classifications and units
coupled with the library. Having only a fixed system would definately not be
very much in the spirit of boost.

The only reason I can see why one might want a fixed system would be for
faster compile-times. Since a general library pretty much has to use
compile-time sequences, compile-times tend to grow. For instance, right now
I internally use MPL maps which still only get nlog(n) for unordered
comparisons returning true, where n is the number of base classficiations of
a given base or derived classification, with some cases resolving to
constant time if the template for comparison with those arguments was
already instantiated or if is_same reports true. A similar type of operation
occurs for comparing unit types as well. Those operations generally have to
be done for any binary operator expression having two quantities for
operands, since it usually has to be determined if they are of the same
classification first, and has to compare the unit types of each operand.

Unfortunately, I see no way around this for a general library and am pretty
sure that nlog(n) is the best we can do, which is unfortunate (which is why
earlier I challenged someone to figure out a better way). How much this will
actually impact compile-times in practice is still hard to tell at this
point in development, since many of those operations will likely be
redundant template instantiations, meaning you should only have that
compile-time overhead once per set of arguments and then it's almost free
after that. Exactly how often the same arguments happen to be passed is
difficult to tell without using the library in practice, since the order of
elements in compile-time associative sequences are dependent on the way in
which the sequences are created and modified. Not only that, but nlog(n)
isn't a terrible complexity anyway, especially considering most of the
classifications will only have between 0 and 5 fundamental classifications
or units which make them up. Still, it's obviously not better than being
always performed in constant time, as if a fixed set were used.

There is another solution I have come up with, though, which has the
benefits of both approaches. If compile-times prove to be too long, an
adaptor could be developed which takes a group of classifications created by
the general library and converts them to a "system" such as those described
earlier, where you can optionally only use units together from that system
in certain contexts. Such a system could often have constant time
classification comparisons as well as have other optimizations unavailable
with a strictly general approach. This would probably be the ideal solution,
since you still have the general library as the basis and are able to use
all units with each other when needed, but you can also optionally pull a
subset of any of the infinite number of classifications which could be
created for that library into their own subset for situations which need
better compile times or which you don't want to intermingle with other
units. Not only that, but since the classifications of those systems come
from the general library, an explicit conversion could easily be made to
convert quantities back to a general representation to be used with any
other units once calculations are done on them in the fixed system (not a
good idea to have such a conversion implicit since it defeats the purpose of
systems). This way, you can create systems for optimizations or just for
logical groupings without impacting how general the rest of the library is,
and it doesn't make the overall library much more complex either.

I'm not going to think about creating such an adaptor just yet since I'm
caught up with finishing the rest of the general library, but I'm tossing
the idea up into the air for people to see. It should provide a way to have
the best of both worlds without having to have two completely separate
libraries, and it wouldn't be too difficult to implement once we get to that
point in time. Opinions on such an approach would be nice now, though.

On 10/21/05, David Abrahams <dave_at_[hidden]> wrote:

> Matt wasn't talking about that "feature." Note that the implicit
> conversion he mentioned is a widening one, which is always okay.
>

Thank you! Someone understands the point I was making. I was a little
worried when everyone started talking about unrelated conversions after that
post.

--
-Matt Calabrese