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

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-27 12:06:48

> Practically speaking, when developing such a technically minded  
> piece of
> software, approximately 30% of the development effort goes into the
> computation kernel whereas the remaining 70% of the effort goes to the
> overall infrastructure, business layer, presentation layer (batch,  
> gui,
> api,..), interoperability, productizing etc.  It is sad to say, but  
> such
> is life.

A Boost library isn't mandated to completely solve all aspects of a  
given problem domain for all potential users. I could easily have  
written a
comparably negative review of, for example, GIL because it doesn't  
meet my specific needs. However, it appears to be fine for the purposes
that many users intend to use it for. Similarly, one could argue that  
the Boost quaternion/octonion library is too restricted - why not  
implement
complete Clifford algebras instead? And, as has been noted, that  
library also does not provide transparent support for 3D graphics  
applications
that are the most likely candidates for real-world use of  
quaternions. In any case, like most Boost authors, I wrote a library  
that was useful for
my applications - in research, I spend basically all my time  
implementing and testing new equations and have little or no use for  
GUI features.
I certainly am not arguing that what you're asking for is not useful  
- but if you wanted to submit a runtime unit library to Boost, should  
I reject it
because it incurs runtime overhead that is not acceptable to me? At  
this point, unfortunately, either a unit library does or does not  
incur this
runtime overhead - for some users it is acceptable and for others it  
is not. I would be delighted to see you put forth your library as a  
complementary
contribution to Boost and help ensure interoperability. I don't  
really understand why this particular topic appears to have become a  
zero sum game...

> to implement. Once you are sure what you are doing, you go and  
> implment
> it (using plain dimensionless floating point arithmetic). That worked
> well for over 50 years now.

The Mars Climate Orbiter team would disagree with this assessment...

http://www.space.com/news/orbiter_error_990930.html

> apply some fancy transforms beforehand to basically make all numbers
> dimensionless, but then you dont need a unit library anyway. Similar
> situations occur in all kind of fluid dynamics, finite difference,
> finite element codes, dynamic simulation codes and the like.

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

> the units _really_ match in every possible case. And there are lots of
> cases possible. If they do not match, a conversion is usually
> acceptable, as it does not happen over and over again. We also talk
> about serialisation aspects here. Language dependend output (as
> suggested for future development in the documentation) to files is an
> absolute no-go: Otherwise the file saved by one engineer will not be
> able to get read by his collegue, only because they do not have the  
> same
> language setting.

The current submission fully supports Boost.Serialization which  
provides language-independent input and output of units and quantities.

> Furthermore, many times, you do not know wile writing the software,  
> what
> kind of quantity you actually handle. This is not so true for  
> compuation
> kernels but more for backend storage that abstractly handles  
> results of
> one computation over to some other computation, some postprocessing
> tools or the like. Nevertheless correct unit handling is  
> indispensable.

If you are going to work in a fixed internal unit system, you can use  
explicit unit conversion through the constructor to do user input.

> distinguishable somehow, but the author does not tell us 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. No library can  
substitute for a complete understanding of the problem 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.  
However, in general a unit may be expressed in many ways if you allow  
a non-orthogonal basis, so there is no general solution that can  
unambiguously assign a set of fundamental and derived units to it.  
You could possibly reduce it to the minimal combination of  
fundamental and derived units, but this may not give the user what  
they expect, either...

> I have yet to see any stringend need for rational exponents. They  
> rather
> obscure the physical meaning of certain terms, imho.

Some people need them.

> To define all possible conversions of n unitsystems, you'll need about
> O(n*n) helper structs to be defined. I may be overlooking some more
> elaborated automatism, though. However, we are likely to face a larger
> number of unitsystems as already the conversion of "cm" in "m"  
> requires
> different systems.

There is no way around this if you want to avoid having a common unit  
system through which all conversions occur. The reasons why that is a  
bad idea have been exhaustively discussed in previous conversations  
in this mailing list on the topic. Furthermore, we may want to only  
allow implicit conversions to go in one direction, so two  
specializations are needed for each pair of units.

> The handling of temperatures (affine units in general) is correct but
> not very practical.

I'd be happy to hear of a more practical solution that preserves the  
zero runtime overhead of the library.

>> From the technical aspects, this library looks probably good. My
> objections focus on the semantic level.

Thanks for your input.

Matthias