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

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-03-27 16:50:33

On 3/26/07, Martin Schulz <Martin.Schulz_at_[hidden]> wrote:
>
> B) The presentation layer consists of everthing that is visible to the
> user, namely the GUI or the like. People in academics can hardly imagine
> what expectations engineers might have towards the units of their data.
> (Before entering industry, I was no exception to that rule :-) )  This
> is partly due to historical reasons; the choice of units in the
> presentation layer may vary by corporate guidelines, personal
> preference, professional background of the user or geographical
> location. If you want to get around with a single piece of code then,
> you cannot live with a fixed units for the quantities in your program.
> (The presentation layer, that is -- computation kernels are another
> story.)

I'm a little unclear on why some people think run-time support is
required for robust interaction with GUIs.  It could very well be a
misunderstanding on my part, but with a user interface that allows
arbitrary units, wouldn't you still need something like this:

// Assume quantity<abstract> provides run-time support
quantity<abstract> on_dialog_ok()
{
        int selection = get_combobox_selection(ID_COMBO_DISTANCE);
        double value = get_editbox_value<double>(ID_EDIT_DISTANCE);
        quantity<abstract> distance;

        // This must be kept in sync with the dialog resource
        switch (selection)
        {
                case Meters:
                        distance.reset(distance * meters);
                        break;
                case Feet:
                        distance.reset(distance * feet);
                        break;
                // etc
        }
        return distance;
}

FWIW, the compile-time version of the above function looks very
similar.  You still have to have a case for each type, the only
difference is that you have to decide during implementation what unit
to convert everything to.

Granted, the run-time version allows things like:
// Note: conversion takes place behind the scenes here,
// and you don't know which way the conversion happens.
// Is this comparison done in meters or in feet?
if (distance_in_meters > distance_in_feet)

(Aside: Not that I have any understanding of the complexities
involved, but wouldn't it be cool if the run-time component
automatically chose the correct unit that would maximize precision?
If it knew an overflow wouldn't happen, wouldn't doing the arithmetic
at the largest level possible always be better?  (e.g. feet + meters
would be done in meters, feet + nanometers would be done in feet)

>From my understanding, the run-time component allows mixed unit
arithmetic.  It allows for a nice syntax, but if one wants control
over which way the conversion takes place, the user will still need to
resort to being explicit (casts or constructors), at which point he
has the same (or very similar) syntax as the compile-time version,
except he's paying a run-time cost as well.

I'm not saying that a run-time version isn't needed, just that I don't
understand the use cases yet, nor do I understand why a compile-time
component isn't useful enough to be included in Boost as is.

> As another example, consider simply a nifty small graph plotting widget.
> Clearly enough, this widget must handle whatever unit may arrive.
> Furthermore, users may decide to add or multiply some channels or
> combine them by some other means. Therefore the arithmetic operations
> for units are necessary at the runtime of the program.

Why wouldn't that widget use some base underlying unit and just
convert all incoming values?

--Michael Fawcett