Re: [boost] Boost Units library preview
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Monday, August 21, 2006 3:55 PM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ecd87h$brg$1@sea.gmane.org...
Eric Lemings wrote:
This brings up a good question. Say you have two objects:
meters m = 1; feet f = 2;
What is the type (or unit) of the following expression?
m + f;
I apologize for repeating myself, but I want this to fail to compile. I do not want implicit conversion of units. I believe I am not completely alone in this view.
Could you provide your rationale for wanting expressions like this to fail? Maybe there is something we've overlooked?
Personally I love implicit unit conversions. :-)
I'm inclined to agree. As long as the dimensions are correct and a.) the result type is the dimension of the unit, or b.) the programmer specifies the desired units, I don't see a problem with implicit conversions between quantities (measures, whatever) of compatible dimensions and units. Eric.
Eric Lemings writes: [...]
This brings up a good question. Say you have two objects:
meters m = 1; feet f = 2;
What is the type (or unit) of the following expression?
m + f;
I apologize for repeating myself, but I want this to fail to compile. I do not want implicit conversion of units. I believe I am not completely alone in this view.
Could you provide your rationale for wanting expressions like this to fail? Maybe there is something we've overlooked?
Personally I love implicit unit conversions. :-)
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific. If (either) units library fails to provide both capabilities, it will be unusable for some category of projects. I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways. ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation - Douglas Hofstadter dgsteffen at numerica dot us
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.14441.683655.649056@yttrium.numerica.us...
Eric Lemings writes: [...]
This brings up a good question. Say you have two objects:
meters m = 1; feet f = 2;
What is the type (or unit) of the following expression?
m + f;
I apologize for repeating myself, but I want this to fail to compile. I do not want implicit conversion of units. I believe I am not completely alone in this view.
Could you provide your rationale for wanting expressions like this to fail? Maybe there is something we've overlooked?
Personally I love implicit unit conversions. :-)
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific.
If (either) units library fails to provide both capabilities, it will be unusable for some category of projects.
I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways.
What? By means of a Macro switch in the config header? regards Andy Little
Andy Little writes:
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.14441.683655.649056@yttrium.numerica.us...
Eric Lemings writes: [...]
> This brings up a good question. Say you have two objects: > > meters m = 1; > feet f = 2; > > What is the type (or unit) of the following expression? > m + f;
I apologize for repeating myself, but I want this to fail to compile. I do not want implicit conversion of units. I believe I am not completely alone in this view.
Could you provide your rationale for wanting expressions like this to fail? Maybe there is something we've overlooked?
Personally I love implicit unit conversions. :-)
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific.
If (either) units library fails to provide both capabilities, it will be unusable for some category of projects.
I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways.
What? By means of a Macro switch in the config header?
I don't know. Yeah, maybe. Or maybe by having two namespaces, and the user grabs stuff out of namespace UnitConverts or namespace UnitsDontConvert. The mechanism is a design decision; I'm just saying that the users are gonna want it. [ and in another email ]
BTW what is wrong with a nocast(t) scheme ?
Ugly. Not syntactically easy, simple, and obvious. If people are going to really use a units library, the syntax has to be indistinguishable from builtins. Note that an automatically-unit-converting library can use a nocast scheme (I think that's what nocast() means), while an automatically-non-unit-converting library would support unit conversions via explicit casts, e.g. overloading static_cast or numeric_cast or something. It's really a question of what the default behavior is. I think there are two completely different uses for this library. On the one hand, units are handy to have around if they do all the unit conversion for you, so you never care if a temperature is in Farenhight, Celcius, or Kelvin; they all work out the details. On the other hand, for other applications, adding feet and meters is indicative of a serious programming error, and _must_ fail compilation. (E.G. that unfortunate Mars probe.) Succincly, the former is convenience, and the latter is correctness. Both are legitimate uses, but they demand very different semantics. If you're going to provide both semantics with the same library (which I think you should), you need a way to specify which one you want, in a way that looks very natural; which IMHO means that the unit-full objects walk, talk, smell, and taste like builtin types. I don't know how to do that, but I'm absolutely sure it's what your users want. ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation - Douglas Hofstadter dgsteffen at numerica dot us
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.19283.854773.973499@yttrium.numerica.us...
I don't know how to do that, but I'm absolutely sure it's what your users want.
Sorted as a quick test in my local copy of Quan FWIW. I added a metafunction to query the unit : allow_implicit_unit_conversions<StaticUnit>::type // bool_ true or false (of fixed_quantity<StaticUnit,NumericType>) Modified the fixed_quantity ctor to query the unit. added a conditional explicit ctor allowing conversions and voila: #include <quan/length.hpp> int main() { quan::length::m L1(1); quan::length::mm L2 = L1; // line 6 L1 + quan::length::m(L2); // ok } e:\Projects\Test\test.cpp(6) : error C2440: 'initializing' : cannot convert from 'quan::length_<Value_type>::m' to 'quan::fixed_quantity<StaticUnit,NumericType>' with [ Value_type=quan::quantity_traits::default_value_type ] and [ StaticUnit=quan::meta::unit<quan::meta::components::of_length::abstract_quantity,quan::meta::si_unit::milli>, NumericType=quan::quantity_traits::default_value_type ] Constructor for class 'quan::fixed_quantity<StaticUnit,NumericType>' is declared 'explicit' with [ StaticUnit=quan::meta::unit<quan::meta::components::of_length::abstract_quantity,quan::meta::si_unit::milli>, NumericType=quan::quantity_traits::default_value_type ] Also works for addition etc. In this quick mod a Macro decides whether the particular implementation of a StaticUnit returns true or false. but you could create a Static where that is a policy parameter I guess.. I'm not sure if this is important enough to do that, but if it is, it is no great problem to add it. regards Andy Little
On Aug 22, 2006, at 7:51 AM, Andy Little wrote:
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.14441.683655.649056@yttrium.numerica.us...
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific.
If (either) units library fails to provide both capabilities, it will be unusable for some category of projects.
I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways.
What? By means of a Macro switch in the config header?
If we really need it, then better with a template parameter in the classes so that both can coexist Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:5639A1B4-1BA8-4D1E-852F-0B07F3BCFC3A@itp.phys.ethz.ch...
On Aug 22, 2006, at 7:51 AM, Andy Little wrote:
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.14441.683655.649056@yttrium.numerica.us...
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific.
If (either) units library fails to provide both capabilities, it will be unusable for some category of projects.
I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways.
What? By means of a Macro switch in the config header?
If we really need it, then better with a template parameter in the classes so that both can coexist
Actually, just experimenting with using this feature shows it to be quite useful. I only experimented with one example and tried changing one length unit to millimeters whereas previously it was meters. The ensuing game then was to try to get the code to compile without using any explicit unit conversions. ( You need to understand the semantics of Quan to understand that it is possible, using SI units, to work ,for example in picometers, with exactly the same accuracy as you get with meters, but you would need to study the docs ( and maybe code) in some detail to see why this is possible). I found I had to change velocity from m.s-1 to mm.s-1. Then forces to mN. I was finally left with one constant , air_density, originally with a value of 1.225 kg.m-3. which I had to change to 1.225e-9 Tg.m-3, at which point the code compiled OK without requiring any explicit conversions. (Each conversion representing a loss in speed and accuracy) It is clear from the above that the original choice of meters is probably best because of the very small air density value, but in another application perhaps different units would be a better choice. Even sticking with meters ( and 'user units' of millimeters), using the macro switch showed that some optimisation could be done by changing units of various functions and so on. So I reckon I'll leave this feature in the Quan toolbox :-) regards Andy Little
"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17642.14441.683655.649056@yttrium.numerica.us...
Eric Lemings writes: [...]
This brings up a good question. Say you have two objects:
meters m = 1; feet f = 2;
What is the type (or unit) of the following expression?
m + f;
I apologize for repeating myself, but I want this to fail to compile. I do not want implicit conversion of units. I believe I am not completely alone in this view.
Could you provide your rationale for wanting expressions like this to fail? Maybe there is something we've overlooked?
Personally I love implicit unit conversions. :-)
Comment from the back row: Some people will want automatic conversions. Some people will want a compilation failure. Both are perfectly reasonable behaviors, and which one is appropriate is project specific.
If (either) units library fails to provide both capabilities, it will be unusable for some category of projects.
I don't know how to control this, nor what the interface should look like, but I am certain that a good units library will be able to go both ways.
BTW what is wrong with a nocast(t) scheme ? regards Andy Little
participants (4)
-
Andy Little -
Dave Steffen -
Eric Lemings -
Matthias Troyer