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

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-20 12:37:04

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

> What are the "fundamental types" that are being referred to here? I'm
> guessing that it is the basis set for the dimensional analysis, and
> hence would be something like: length, time, mass, temperature,
> intensity, current, amount.
>
> Is this a fixed set, or can it be overridden (not just extended)? (This
> is what, if memory serves, was one of the major points of discussion
> back in 2003/2004.)

By fundamental types I meant base unit classifications such as length, etc.
yes. You can add your own easily anywhere with one line anywhere in code. I
posted the code to do so earlier in this thread already. You can use that
classification with any other classifications, for instance, you can create
"currency" and use currency/time. This is all covered already earlier in the
thread.
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.

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:
>
> can I constrain what various parts of the
> code are doing so that that expression would be invalid because
> "physical quantities" do not have a "bedknobs" dimension?

No. I don't really see the benefit of that.

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:
> SI::length<double> footInMeters = convert_units<SI>(foot);
> which would store a value of 0.3048 in footInMeters (since the internal
> representation is in units of meters). Personally, I'm with Deane Yang:
> I don't like implicit conversions.

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.

Even Deane's example of why he wanted the functionality seemed completely
specific to the way his project worked. Adding years to months in his case
isn't unnacceptable because they are different units, it's just that he
chose to use years and months in two separate modules, and just in the case
of that project, he wouldn't ever need to add what the represent together.
It's not because it doesn't make sense to add the concept of years with
months. Changing the example slightly to better explain, one could very well
have two different modules only now both are using years, though you may not
logically ever want to add them together. The fact that you don't want to
add them together really has no direct link to the fact that they are
different units or the that they are the same units, but because at a higher
level in your project than the quantities themselves, you shouldn't have to
be adding them together. This type of abstraction, in my opinion, has
absolutely no reason for being expressed at the library level. If you want
that functionality, again, it's because of restrictions at a higher level in
code than just "quantities". In actuality, I'd say the better solution, even
if explicit conversions were forced by the library, would be for you to make
a type which encapsulates one concept and a different type which
encapsulates the other concept, since that higher level abstraction is what
disallows the conversion, not the fact that they are different units.

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.
On 10/20/05, Phil Richards <news_at_[hidden]> wrote:
>
> I've never actually needed this
> level of functionality, so I've never be inclined to wonder
> whether it was overly restrictive or not :-)

Neither do I. Length plus length is fine. Mass minus mass is fine. Time
divided by time is fine. The underlying units used are merely implementation
details. Restricting such operations merely because the underlying units of
the dimensions are different does not make sense. They represent the same
exact thing! Right now, the only exceptions to this rule that I see occur in
abundance with dimensionless quantities, such as with radians and
steradians, since implicit conversion between them doesn't make logical
sense, despite the fact that they are of the same derived classification.

Also, I wanted a version out for people to play with earlier this week, but
with all of the discussion from last week and the amount of work I have to
do this week, you'll have to wait a little bit longer; I'm just going to try
to finish up getting expression rearrangement fully completed, as at the
moment it's half-implemented. Toggles to turn individual optimizations off
won't be implemented yet so that I can get it out earlier for people to use.

--
-Matt Calabrese