Re: [Boost-users] [units]

Subject: Re: [Boost-users] [units]
From: Michael Powell (mwpowellnm_at_[hidden])
Date: 2011-08-30 10:40:49

On Tue, Aug 30, 2011 at 8:01 AM, Thomas Taylor
<thomas.taylor_at_[hidden]>wrote:

> Michael Powell wrote:
>
> > On Tue, Aug 30, 2011 at 6:29 AM, Michael Powell
> > <mwpowellnm_at_[hidden]>wrote:
> >
> >>
> >>
> >> On Tue, Aug 30, 2011 at 2:04 AM, Thomas Taylor
> >> <thomas.taylor_at_[hidden]
> >> > wrote:
> >>
> >>> Could you please review the following patch for inclusion in
> >>> boost::units?
> >>>
> >>> *WHY*: Obviously this only defines a conversion for boost::units::one
> to
> >>> a numerical 1. When trying to convert at runtime (aiming for a
> >>> runtime/dynamic
> >>> unit instead of the compiletime/static unit provided) I use the
> >>> following function:
> >>>
> >>> template <typename U1, typename U2>
> >>> double unit_dispatch2t(U1 const& u1, U2 const& u2) {
> >>>    return bu::conversion_factor(u1,u2);
> >>> }
> >>>
> >>> where U1 and U2 are boost::unit::unit derivatives.
> >>>
> >>> Without a conversion operator the compiler chickens out by claiming to
> >>> not be able to convert boost::units::one to (in my case) double. The
> >>> added conversion operator allows successfull compilation, thus allowing
> >>> actual runtime units (my application needs to handle calculations where
> >>> some units
> >>> are known at compiletime and some only at runtime (e.g. the user wants
> >>> the calculation to be done in meters or millimeters)).
> >>>
> >>
> >> Oh, the runtime question. Here's how we've decided to approach this.
> >>
> >> I'll just tell you, I find the compile-time safety attractive. For
> >> runtime, we've decided that calculations should be done in a base unit.
> >>
> >> For anything else, we *convert to* a view unit, for display or report or
> >> what not.
> >>
> >
> > I should clarify too, in this type of use case, we still know what the
> > compile-time units should necessarily be. The runtime I like to think of
> > is the user selecting: system, and possibly also unit. Which is what your
> > aiming for here?
>
> No, I don't think so. If I read your answer correctly your appoach
> advocates
> to decide on a specific unit for calculation (which is specified at compile
> time). IO will be converted to/from a unit of the users choosing (at
> runtime).
>

Yes, that's correct. We'll always perform calculations in a base unit, but
we'll present a view unit when it comes time to select the system and/or
units involved.

Side bar, in this industry, at this company, certain assumptions were made
about the "formulas" involved, which get away from the actual science or
real calculations of it. At least that's their background, and seems to be
universities' approach to training. But you need to understand that guys n
the field getting trained have a working knowledge of it, not a UOM
knowledge of it. They obviously didn't upload any code to any Mars orbiters
recently (that's the case study I like to present).

So when I suggested that calculations be performed in the base unit using
the correct calculations, I was almost balked at. I said, this number here,
0.00981, is really acceleration due to gravity in disguise. That was week
one of my job. They eventually came around and bought into the idea, but my
god, what a "novel" concept it must be that calculations, and necessarily
UOM, should be correct. Which is how I've justified using a boost::units,
what makes compile time checking so attractive, so that we can trap obvious
stupid errors, whatever dimension / unit we are considering.

Anyhow, that's my soap box rant for the day...

However I explicitely want to decide at runtime which unit the *calculation*
> will be in and I believe I have a working approach (which would require the
> aforementioned patch as it is impossible to define such a conversion
> anywhere else unless I am mistaken).
>

Not to say you can't perform calculations in any units of your choosing,
because you can. My only question there is, why would you want to?

What I'm advocating is convert to the user's desired units in a view, but
let the calculation happen in a base unit. Anyway, that's been our approach
thus far.

Certainly my use case will not fit every problem (maybe even just my own),
> but is there a specific reason NOT to include a boost::unit::one to
> integer/POD conversion, i. e. will it break existing code?
>
> If the proposed change is deemed unacceptable, do you think a modification
> that allows to choose either the default boost::unit::one or a costum home
> brew one will make it into the repository?
>

Personally, I don't know enough about boost::units to say so. Since I don't
know your system or your approach, do take our approach with a grain of
salt.

My opinion along these lines is that general-purpose units should
necessarily be considered. Such as gallons, oil barrels, etc. These are
general enough to be useful not only for us in our application, but also
others. Call it our contribution to community, much less society, as far as
these things can be measured.

Thanks for pointing out the current philosophy on runtime unit support.
>

'Tis one opinion, one approach. Of course, it runs under the assumption how
boost::units seems to lend itself to that approach, saying nothing about
other UOM systems, and there aren't many to choose from, so the field is
rather narrow, even though the concepts are very similar, and well UOM is
UOM whatever implementation you go with.

Cheers,
> Thomas
>

Best regards.

> >
> > Use case: calculations on volume, pressure, etc, done in base SI units.
> > View
> >> may be in SI, US (English), or what have you.
> >>
> >>  HTH,
> >>> Thomas
> >>>
> >>>
> >>>
> >>> --- one.hpp     2011-08-30 09:50:13.000000000 +0200
> >>> +++ one2.hpp    2011-08-30 09:50:07.000000000 +0200
> >>> @@ -19,3 +19,3 @@
> >>>
> >>> -struct one { one() {} };
> >>> +struct one { one() {} operator int() { return 1; } };
> >>>
> >>>
> >>> _______________________________________________
> >>> Boost-users mailing list
> >>> Boost-users_at_[hidden]
> >>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >>>
> >>
> >>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>