On Tue, Aug 30, 2011 at 8:01 AM, Thomas Taylor <thomas.taylor@univie.ac.at> wrote:

Michael Powell wrote:

> On Tue, Aug 30, 2011 at 6:29 AM, Michael Powell
> <mwpowellnm@gmail.com>wrote:
>
>>
>>
>> On Tue, Aug 30, 2011 at 2:04 AM, Thomas Taylor
>> <thomas.taylor@univie.ac.at
>> > 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@lists.boost.org
>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>>
>>
>>

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users