Hi Andy, This is my tranlation of the brief comments of one of my Danish friends who has great experiance with unit-libraries: --------------Translation begin: I had a quick look at Andy's proposal while I was travelling. My immediate impression of the proposal based on the documentation was faily mixed. I feel that the proposal is unnecessary complex compared to the other solutions I know (including our own): Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001) Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003) We have used compile-time SI types for the last 3-4 years in our products (remark: software for windmills in the world largest windmill company) and I have never missed the extra functionality Andy is offering compared to the two above proposals. In particular, I find all the machinary concerning formatted I/O unneccessary. Physical quantities is often used in connection with with process control, where the primary IO units are not cin and cout. Not even in connection with HMI have we had a need for the stream support the proposal offers. On the contrary, we often want internationalization, which fits badly with an output format controlled by compile-time types. In generel I have a hard time understanding the motivation for introducing unit-types instead of just quantity types. Personally I prefer length x = 10 * meter(); to length::m_div_s x(10) because the former is closer to the syntax from the real SI system. At some level I feel Andy's solution is a step in the wrong direction compare to the above articles. The level of abstraction feels lower even though the implementation is probably more complex. Jeg feel I'm lacking a rationale to why Andy has chosen an interface that deviates from "mainstream" solutions on a number of key areas. If the argument for unit-type alone is to support C++ standard streams directly, I can't support the proposal. Kind regards Jesper ----------------- Original message: Jeg nåede lige at kaste et kort blik Andy's forslag mens jeg stadig var under sydlige himmelstrøg (jeg skulle nok have lavet et review mens jeg holdt orlov). Mit umiddelbare indtryk af forslaget ud fra den medfølgende dokumentation var dog noget blandet. Jeg føler at forslaget er unødigt komplekst i forhold til de andre løsninger jeg kender (inklusivt vores eget forsøg). Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001) Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003) Vi har brugt compile-time SI typer gennem de sidste 3-4 år i vores produkter og jeg har aldrig savnet den ekstra funktionalitet Andy tilbyder i forhold til de to ovenstående forslag. Specielt finder jeg alt maskineriet omkring formatering af input og output for unødvendig. Fysiske størrelser bruges typisk i forbindelse med process kontrol, hvor de primære IO enheder ikke er cin og cout. Hellere ikke i forbindelse med HMI har vi haft brug for den stream support som forslaget tilbyder. Tværtimod ønsker vi ofte internationalisering, hvilket harmonerer dårligt med et output format, der er styret af compile-time typer. Helt generelt har jeg svært ved at forstå motivationen for at indføre unit typer frem for blot quantity typer. Personligt fortrækker jeg "length x = 10 * meter() / second()" frem for "length::m_div_s x(10)" fordi det første minder mest om den syntaks vi kender fra det virkelig SI system. På en eller anden måde føler jeg at Andy's løsning er et skridt i den forkerte retning i forhold til de to ovenstående artikler. Abstraktionsniveauet føles lavere selvom implementationen formentlig er mere kompleks. Jeg synes jeg mangler et rationale, der beskriver hvorfor Andy vælger et interface, som afviger fra "mainstream" løsningerne på en række fundamentale områder. Hvis argumentet for at indføre unit typer alene er at kunne understøtte C++ standard streams direkte, så kan jeg ikke støtte forslaget. Med venlig hilsen Jesper
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:44894631.8020602@dezide.com...
Hi Andy,
This is my tranlation of the brief comments of one of my Danish friends who has great experiance with unit-libraries:
--------------Translation begin: I had a quick look at Andy's proposal while I was travelling. My immediate impression of the proposal based on the documentation was faily mixed. I feel that the proposal is unnecessary complex compared to the other solutions I know (including our own):
Ok.
Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001)
Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003)
We have used compile-time SI types for the last 3-4 years in our products (remark: software for windmills in the world largest windmill company) and I have never missed the extra functionality Andy is offering compared to the two above proposals.
Well.. at least it sounds like PQS covers your current functionality!
In particular, I find all the machinary concerning formatted I/O unneccessary. Physical quantities is often used in connection with with process control, where the primary IO units are not cin and cout. Not even in connection with HMI have we had a need for the stream support the proposal offers.
The main utility I see is for debugging, logging,data tracing etc. PQS I/O is modular so you dont need to include it unless you want it.
On the contrary, we often want internationalization, which fits badly with an output format controlled by compile-time types.
Its true that the current output format is fixed, but I disagree that this is because of the compile-time types. A locale facet type functionality has been suggested for internationalisation. compile-time types dont rule that out AFAICS.
In generel I have a hard time understanding the motivation for introducing unit-types instead of just quantity types. Personally I prefer
length x = 10 * meter();
to
length::m_div_s x(10)
because the former is closer to the syntax from the real SI system.
FWIW this syntax is trival in PQS: typedef pqs::length::m length; typedef pqs::time::s time; typedef pqs::velocity::m_div_s velocity; length meter(){return length(1);} time second(){return time(1);} velocity x = 10 * meter() / second(); IOW If you prefer to work this way you can.
At some level I feel Andy's solution is a step in the wrong direction compare to the above articles. The level of abstraction feels lower even though the implementation is probably more complex. Jeg feel I'm lacking a rationale to why Andy has chosen an interface that deviates from "mainstream" solutions on a number of key areas. If the argument for unit-type alone is to support C++ standard streams directly, I can't support the proposal.
Thanks for the review. regards Andy Little
Kind regards
Jesper
----------------- Original message: Jeg nede lige at kaste et kort blik Andy's forslag mens jeg stadig var under sydlige himmelstrg (jeg skulle nok have lavet et review mens jeg holdt orlov). Mit umiddelbare indtryk af forslaget ud fra den medflgende dokumentation var dog noget blandet. Jeg fler at forslaget er undigt komplekst i forhold til de andre lsninger jeg kender (inklusivt vores eget forsg). Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001) Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003) Vi har brugt compile-time SI typer gennem de sidste 3-4 r i vores produkter og jeg har aldrig savnet den ekstra funktionalitet Andy tilbyder i forhold til de to ovenstende forslag. Specielt finder jeg alt maskineriet omkring formatering af input og output for undvendig. Fysiske strrelser bruges typisk i forbindelse med process kontrol, hvor de primre IO enheder ikke er cin og cout. Hellere ikke i forbindelse med HMI har vi haft brug for den stream support som forslaget tilbyder. Tvrtimod nsker vi ofte internationalisering, hvilket harmonerer drligt med et output format, der er styret af compile-time typer. Helt generelt har jeg svrt ved at forst motivationen for at indfre unit typer frem for blot quantity typer. Personligt fortrkker jeg "length x = 10 * meter() / second()" frem for "length::m_div_s x(10)" fordi det frste minder mest om den syntaks vi kender fra det virkelig SI system. P en eller anden mde fler jeg at Andy's lsning er et skridt i den forkerte retning i forhold til de to ovenstende artikler. Abstraktionsniveauet fles lavere selvom implementationen formentlig er mere kompleks. Jeg synes jeg mangler et rationale, der beskriver hvorfor Andy vlger et interface, som afviger fra "mainstream" lsningerne p en rkke fundamentale omrder. Hvis argumentet for at indfre unit typer alene er at kunne understtte C++ standard streams direkte, s kan jeg ikke sttte forslaget. Med venlig hilsen Jesper _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Andy Little" wrote: [ PQS ]
On the contrary, we often want internationalization, which fits badly with an output format controlled by compile-time types.
Its true that the current output format is fixed, but I disagree that this is because of the compile-time types. A locale facet type functionality has been suggested for internationalisation. compile-time types dont rule that out AFAICS.
The I18n may be too hard problem to deal with. For example in Czech language there are at least two "per" (as in m_per_s) variants used in different contexts. /Pavel
Andy Little said: (by the date of Fri, 9 Jun 2006 16:11:14 +0100)
FWIW this syntax is trival in PQS:
typedef pqs::length::m length; typedef pqs::time::s time; typedef pqs::velocity::m_div_s velocity;
length meter(){return length(1);} time second(){return time(1);} velocity x = 10 * meter() / second();
IOW If you prefer to work this way you can.
It's a very interesting idea! Maybe you could provide some extra header file that will provide such functionality? Those functions - being inline should not even affect the runtime speed? mixed units (like velocity) would then default to the base si units (like m/s in this case) -- Janek Kozicki |
Janek Kozicki wrote:
Andy Little said: (by the date of Fri, 9 Jun 2006 16:11:14 +0100)
FWIW this syntax is trival in PQS:
typedef pqs::length::m length; typedef pqs::time::s time; typedef pqs::velocity::m_div_s velocity;
length meter(){return length(1);} time second(){return time(1);} velocity x = 10 * meter() / second();
IOW If you prefer to work this way you can.
It's a very interesting idea!
Yes, definitely. I like this solution very much. -Dave
David A. Greene said: (by the date of Fri, 09 Jun 2006 21:23:21 -0400)
Janek Kozicki wrote:
Andy Little said: (by the date of Fri, 9 Jun 2006 16:11:14 +0100)
FWIW this syntax is trival in PQS:
typedef pqs::length::m length; typedef pqs::time::s time; typedef pqs::velocity::m_div_s velocity;
length meter(){return length(1);} time second(){return time(1);} velocity x = 10 * meter() / second();
IOW If you prefer to work this way you can.
It's a very interesting idea!
Yes, definitely. I like this solution very much.
Adding those definitions to the headers should make things even simpler and more user friendly! With above definitions, and with macro that I have described in another post (titled "Re: [boost] [review] pqs - defining own units" ) #define BOOST_UNITS_DIVIDED(numerator,denominator,new_type) \ typedef /*typename */ pqs::meta::binary_operation< \ numerator, \ pqs::meta::divides, \ denominator \ >::type new_type \ I can use this macro, but define a friendlier name: BOOST_UNITS_DIVIDED(pqs::force::N,pqs::length::m,spring_stiffness); And now I can write a valid C++ code that really looks good! // in my euqations I use 'kn' to represent spring stiffness spring_stiffness kn = 12 * newton() / metr(); The only drawback would be compile time, and nothing more, I really think that it's worth that. Given that, maybe there is no need at all to define velocity.hpp, pressure.hpp and all the others with dimensions combined? When the user plans to work with velocity he will just write: // requires only this macro BOOST_UNITS_DIVIDED(pqs::length::m,pqs::time::s,velocity); instead of this: // requires file velocity.hpp with dozens of definitions inside typedef pqs::velocity::m_div_s velocity; And now it's the user who makes a choice whether to use name "velocity" or name "m_div_s" or name "m_per_s". And all arguments 'div' versus 'per' become obsolete :) PS: sorry about scattering this single topic into to posts on the mailing list :/ -- Janek Kozicki |
Janek Kozicki writes:
Given that, maybe there is no need at all to define velocity.hpp, pressure.hpp and all the others with dimensions combined? When the user plans to work with velocity he will just write:
// requires only this macro BOOST_UNITS_DIVIDED(pqs::length::m,pqs::time::s,velocity);
instead of this:
// requires file velocity.hpp with dozens of definitions inside typedef pqs::velocity::m_div_s velocity;
or, may be as simple as pqs::velocity?
And now it's the user who makes a choice whether to use name "velocity" or name "m_div_s" or name "m_per_s". And all arguments 'div' versus 'per' become obsolete :)
PS: sorry about scattering this single topic into to posts on the mailing list :/
Oleg Abrosimov said: (by the date of Thu, 15 Jun 2006 14:33:40 +0700)
Janek Kozicki writes:
Given that, maybe there is no need at all to define velocity.hpp, pressure.hpp and all the others with dimensions combined? When the user plans to work with velocity he will just write:
// requires only this macro BOOST_UNITS_DIVIDED(pqs::length::m,pqs::time::s,velocity);
instead of this:
// requires file velocity.hpp with dozens of definitions inside typedef pqs::velocity::m_div_s velocity;
or, may be as simple as pqs::velocity?
and maybe even this: velocity v = 10*meter()/second(); ? -- Janek Kozicki |
Janek Kozicki wrote:
velocity v = 10*meter()/second();
I want to point out that library constructed in such a way willl perfectly fit new "auto" feature that is already in the draft of C++0x (document N2009, clause 5.3.4/2) : auto v = 10*meter()/second(); and will make definitions of the most complex physical units pretty straightforward. B.
"Janek Kozicki" <janek_listy@wp.pl> wrote in message news:20060618012322.39a96ebf@absurd...
Oleg Abrosimov said: (by the date of Thu, 15 Jun 2006 14:33:40 +0700)
Janek Kozicki writes:
Given that, maybe there is no need at all to define velocity.hpp, pressure.hpp and all the others with dimensions combined? When the user plans to work with velocity he will just write:
// requires only this macro BOOST_UNITS_DIVIDED(pqs::length::m,pqs::time::s,velocity);
instead of this:
// requires file velocity.hpp with dozens of definitions inside typedef pqs::velocity::m_div_s velocity;
or, may be as simple as pqs::velocity?
and maybe even this:
velocity v = 10*meter()/second();
?
Yes...that isw hat i am calling a 'view'. IMO thats trivial to do with PQS as I showed in an earlier post and Daid Walthall in a later one ! regards Andy Little
participants (7)
-
Andy Little -
Bronek Kozicki -
David A. Greene -
Janek Kozicki -
Oleg Abrosimov -
Pavel Vozenilek -
Thorsten Ottosen