Re: [boost] [Review] Quantitative units - compile time vs runtime

From: Martin Schulz (Martin.Schulz_at_[hidden])
Date: 2007-03-29 02:39:52

> The Mars Climate Orbiter team would disagree with this assessment...
> 
> http://www.space.com/news/orbiter_error_990930.html

Thank you for the link, that article nicely illustrates what I meant
when I said: "As a matter of fact, you have to ensure that the right
things get in, and the right things get out there [the kernel]. What
happens inside however is a completely different story."

If we may believe the article, that software falls into at least two
parts (say, "kernels", "modules", "packages", "libraries",..) connected
by some interface. While each team did a proper handling within their
part, they did not made sure the they really got (kilometers) what they
expected to get (miles). The issue is particularly tricky as at the same
time, all modules probably have passed the respective quality assurance
tests without any failure...

> Ensuring that an equation is dimensionless is sufficient in 
> all cases...

But then again, there would be no need for a unit library after all. But
since we both feel the need for such a library, we seem to agree that
the handling in dimensionless quantities will not be the overall
solution. (Though it is certainly very helpful in specific situations)

> > of what type 
> > the product (2*meter)*(5*Newton) should actually be and how 
> a compiler 
> > should tell the difference.
> 
> 2 is a scalar value and 5 is a scalar value, so 
> 10*Newton*meter is an energy. Torque is a pseudovector, so 
> two value types whose product forms a pseudovector would 
> result in a torque.

Well basically what makes the difference in my understanding is nothing
more or less than wether the distance and the force are considered
perpendicular or colinear to each other. The "to each other" being the
key word here. But then again, how could that relation be encoded
independendly in the types of the two scalar quantities (2*meter) and
(5*newton)?

> No library can substitute for a complete 
> understanding of the problem domain.

Certainly true, but we draw different conclusions. While you insist on
making a difference, I came to the conclusion, that both torque and
energy should have the very same internal representation. The
interpretation of that internal representation then clearly requires the
understanding of the domain. 

> > The author states that the intent is obviously F  = 2 m kg 
> s^(-2); In 
> > contrast to the author, I personally would naturally expect 
> something
> > like:
> > F = 2.0[N]
> 
> It would be relatively easy to generate specializations for 
> unit output that address the named derived units in the SI system.  

I am afraid, the problem is deeper than that. IMHO and contrary to ad
hoc expectations, the mapping of physical quantities to products of
exponentials of basic units is not injective.

This means the mapping is not invertible. So the mapping generated by
the suggested specializations can at best represent a kind of "maximum
likelihood solution". 

> > rational exponents....
> 
> Some people need them.

Do you know about their background? Could you please elaborate on that?

Yours,
        Martin.