Re: [boost] Re: runtime unit-modifiablephysical-quantitiesusingpqs1-00-01

From: Phil Richards (news_at_[hidden])
Date: 2004-01-09 12:40:01

[sorry for the delay in replying - I'm slowly catching up on this thread]
On Sun, 04 Jan 2004 21:44:23 -0500, Deane Yang wrote:
> David B. Held wrote:
>>  Isn't it about
>> expressing the solution in the problem domain?  Physicists write
>> equations with Joules and Watts, not just N m and lbs.-ft./s.
> I think this summarizes well what I am asking for and why I think the
> physicists who are trying to build a dimensions/units library are going
> off track.

For the record, I am a mathematician/theoretical computer
scientist/commercial software engineer.  (Enough of my CV.)  Only loosely
speaking could I be classified as a physicist (unless you count quantum
theory and general relativity foundation maths :-).  I am approaching this
from a real-world "need to use it/have been using it for an actual project"
point of view.

> It is certainly true that physicists have found that (almost?) all
> physical quantities can be expressed in terms of 7 fundamental
> dimensions and that this observation is very powerful when reconciling
> calculations involving different physical quantities.

Indeed (though ISO have added "bel" and something else that I can't
remember).  It should be pointed out that when the phrase "Dimensional
Analysis" is used with respect to "quantities", it pretty much *only* ever
means "physics-related" - I recommend a google or vivisimo search.  (I
have tried to find some other place that "dimensional analysis" is
performed that doesn't used the normal set, but have yet to find it...
that's just probably bad eyesight.)

> So if you are writing code carrying out this computation, using a
> full-blown physical dimensions library is complete overkill. And, given
> some of the implementations that have been proposed, there is a real
> cost, too.

No, if the library is (fairly) efficient, it *isn't* overkill at all.
The slowest implementation that exists at the moment is the one that
attempts to grant the flexibility that you want.  It can equally be argued
that attempting to support a user-defined set of dimensions is overkill.
(This is *not* a criticism of Matthias - I am impressed at how far he got
with the MPL, which is certainly better than I did :-)

NOTE: I did *not* say "user-defined set of units" - I am all in favour of
allowing the set of units to be extended/replaced.

> On the other hand, the units library I want would allow the programmer
> to define ONLY the units joules and seconds, and it would make sure that
> computations involving seconds, joules, joule-seconds, joules/second,
> joules/second^2, etc. are logically consistent.

You are basically defining your base dimension set as "time" and "energy".
Although I agree with Matthias in that there is nothing special about the
7 "normal" dimensions used, I have to ask "Why?".  You could use the
"overkill" version to do the job, and it would work fine.  (Assume that
the compile time overheads of using a fixed set are no more than a
"flexible" version - is there *another* problem that I've missed?)

> If this computational module needs to interact with another module that
> for some reason uses minutes instead of seconds, then the units library
> can make sure that the proper conversion is made in the interface.

Yes.  I agree.  But unit conversion is orthogonal to dimensional analysis.

> This would be a much simpler library than the physical dimensions
> library, but it would be much more useful and more widely applicable
> library.

No, what you have described is a library that requires dimensional
analysis support: to deal with (sqrt(joule) / root<3>(joule))-type
calculations you need to keep track of dimensions the base dimensions.
(time and energy).

There is definitely something that could be described as a "unit library",
but things defined in it would have trouble interacting with each other:
without dimensional analysis, you can't have multiplicative operations
(apart from with the underlying value_type).

Example:
  joule<double> j(1);
  second<double> s(1);
  // what is typeof(j / s) ?
Without "dimensional analysis"-like functionality, you are stymied - you
aren't going to get something of type "watt", or even something that is
convertible to it.

> It can also be used to build the physical dimensions library, too. In
> fact, I believe that what I am asking for lies at the core of every
> physical dimensions library being proposed. All I am asking is that core
> piece be extracted and made into a standalone library. If you do that, I
> believe that you will be doing the full C++ community a service, instead
> of only those who write physics-related software.

If you can come up with an interface for such a library (and/or use cases
that show how things interact without the need for dimensional analysis),
then I (for one) am more than happy to have a try at it...

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