I've been waiting in anticipation of pqs for some time. I've had to work with dimensioned values several times and could really have used the compile-time checking pqs offers. It is also, IMHO, one of the best practical examples of template metaprogramming. - Please always explicitly state in your review, whether you think the library should be accepted into Boost. I'm disappointed that for now, I would have to reject the library from Boost. I definitely want to see this library make it in but there is one big drawback that's a showstopper for me. Everything is based on powers of 10. More on this below. There are also some improvements I'd like to see that I don't consider showstoppers. I'll comment on those below as well. - What is your evaluation of the design? The everyday user interface is fine. The myriad of concepts and classes to model them can be overwhelming, however. This might be addressed with better documentation. I don't understand the t1_quantity name. It doesn't convey any useful information to me. It needs a better name. Unit naming: pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose) pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power? Why even have the concept of a prefix_offset? It seems unnecessarily confusing to me. Why does mass default to kg rather than g? If these special cases are really needed, then the documentation needs to explain why. Otherwise, I would prefer that everything work similarly to reduce complexity. The big problem with the design is the assumption that every quantity prefix is based on a power of 10. That's fine for SI units but my hope is that pqs will go beyond just SI. It already does with the incoherent_units so there is some precedent here. Even before pqs was put up for formal review, I had planned to make use of it in some computer simulator work that I'm doing. The ability to create units like Megabytes and Mibibytes would help tremendously. Unfortunately, I could not figure out how to create a unit that uses prefixes that are powers of 2. It might be ok to "fake" it if the calculations always stayed within one system (Mibibytes, Kibibytes, etc.) but as soon as one wants to convert Mibibytes to Megabytes it falls apart. If this can already be done, I'd be overjoyed to be corrected. But I could not puzzle it out from the documentation or a cursory look through the implementation. This is a big gap for me and prevents the use of pqs in most of the day-to-day work that I do. There's also the question of what base_dimension these would fit under. "Amount of substance?" It would be nice to be able to extend the types of base_dimension but I recognize that this could be very difficult given the design of pqs::meta::dimension and classes that depend on it. - What is your evaluation of the implementation? I did not thoroughly review the implementation, just glanced at it to answer some questions. Obviously it does not seem to fulfill my requirements as I stated above. I suspect it will be a bit of work to introduce the new flexibility. - What is your evaluation of the documentation? This needs a lot of work. It seems to assume a deep understanding of SI standards and terminology (beyond the unit names and what they mean) and introduces lots of terms itself (abstract_quantity, named_quantity, concrete_quantity, etc.). The presentation is overwhelming. Some specific suggestions: In the introduction section, we have the following statements about rationale: Increases programmer satisfaction What does this mean, exactly? It's very vague and subjective. enhances productivity How, apart from other rationales given? My suggestion would be to organize the rationale like this: * Increases programmer satisfaction and enhances productivity. * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Self documenting, helps code clarity. This is done better in the Rationale section itself. Make the presentation in these two sections similar in structure. The ERD was confusing to me. Can this be drawn in UML or a close-to-some-standard way? Reading through the documentation, one is confronted with the ginormous definitions page almost right away. I'd prefer to see some simple examples of use first. The "Getting started" page is a good start, but would be improved by removing references to the more esoteric terms. Those can come later. The definitions page itself needs many more code examples (for example, for named_quantity). It took me a long time to begin to understand what these terms really mean and I'm still not all the way there yet. I found the colored links to the terms all over the documentation to be distracting. It really interrupted the flow of the text. It would be better to make these links that look like ordinary text but are highlighted/underlined when the cursor moves over them. The links need to be there but they should be less intrusive. Typos (fixes in brackets): [t1_quantity features] The t1_quantity has many similar features to an [a] built-in type... Where used the type returned by typeof will not[neither] be a reference nor have cv-qualifiers. [abstract_quantity_id] The abstract_quantity_id has two roles, the first of which is to distinguish between different but dimensionally_equivalent[ ] abstract_quantities. [Unary operations example] [c]ondition_true [Addition and subtraction] If one type has a coherent_unit and the other has an incoherent_unit the operand with the incoherent_unit will first be converted to a t1_quantity in the nearest coherent_unit( simply found by setting the incoherent_unit[']s[ ]unit_multiplier to 1) [unit_output_symbol] A text symbol representing the unit[ ]of a concrete_quantity in stream output. [Lots of these missing spaces, underscores and first letters of example code through the documentation. Too many to enumerate.] [Stream output overview] The output of units for stream output functions for t1_quantities resolves to 3[three] output formats - What is your evaluation of the potential usefulness of the library? Very. IMHO strong typing is essential when designing large systems. - Did you try to use the library? With what compiler? Did you have any problems? I was going to do some experiments to create my own quantities as described above, but I could not figure out how to do it, so I did not do any testing. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth reading of the documentation with a clear idea of how I wanted to extend the framework. Unfortunately, I discovered that I could not do what I'd hoped to accomplish. - Are you knowledgeable about the problem domain? In the same way most scientists and engineers are. I'm certainly no authority on the formal SI standards. I do have a large amount of experience in computer simulation and have run into the need for this kind of package for "computer units" over and over. It would be nice to have a package that went beyond the SI and its rigid assumptions.
Why does mass default to kg rather than g?
It's likely it does because kg is the preferred unit in the international system for mass http://en.wikipedia.org/wiki/International_System_of_Units#Units
On Tue, Jun 06, 2006 at 09:06:48PM -0400, David A. Greene wrote:
confusing to me. Why does mass default to kg rather than g? If these
Because kg is the SI unit for mass. It is a Good Thing that mass defaults to kg rather than g. Regards -Gerhard -- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 200 1818 For the rest I claim that raw pointers must be abolished.
Gerhard Wesp wrote:
On Tue, Jun 06, 2006 at 09:06:48PM -0400, David A. Greene wrote:
confusing to me. Why does mass default to kg rather than g? If these
Because kg is the SI unit for mass. It is a Good Thing that mass defaults to kg rather than g.
That doesn't answer my question. Why? I don't see why kg as the "SI unit for mass" requires all this prefix_offset stuff. You'd just use pqs::mass:kg, right? -Dave
"David Greene" <greened@obbligato.org> wrote in message news:44872145.6060806@obbligato.org...
Gerhard Wesp wrote:
On Tue, Jun 06, 2006 at 09:06:48PM -0400, David A. Greene wrote:
confusing to me. Why does mass default to kg rather than g? If these
Because kg is the SI unit for mass. It is a Good Thing that mass defaults to kg rather than g.
That doesn't answer my question.
Why?
I don't see why kg as the "SI unit for mass" requires all this prefix_offset stuff. You'd just use pqs::mass:kg, right?
grammes and milligrammes are common units too. The output of socalled coherent quatities is automated so that its not necessary to customise each units ouput. The prefix_offset is necessary to stick the correct prefix on, usually for mass, but also for anything that starts with mass, like 'mass_flow'. Yes its tricky to explain. Hopefully as a user you dont notice all that stuff. It just works!. Clever libary author has hidden it all away ;-) regards Andy Little
Andy Little wrote:
I don't see why kg as the "SI unit for mass" requires all this prefix_offset stuff. You'd just use pqs::mass:kg, right?
grammes and milligrammes are common units too. The output of socalled coherent quatities is automated so that its not necessary to customise each units ouput. The prefix_offset is necessary to stick the correct prefix on, usually for mass, but also for anything that starts with mass, like 'mass_flow'.
Here's my expectation. Tell me if I'm wrong: pqs::mass:g grams(10); pqs::mass:kg kilograms(10); cout << grams << endl; cout << kilograms << endl; cout << kilograms + grams << endl; I'd expect to see something like this: 10 g 10 kg 10.01 kg How does this involve prefix_offset at all? What's the point of it? How is mass different than, say, length in this regard? If prefix_offset is not exposed to the user at all, then I submit that it serves no useful function in the library and only makes the implementation (and extensions) unnecessarily difficult. -Dave
"David Greene" <greened@obbligato.org> wrote in message news:448740C9.10308@obbligato.org...
Andy Little wrote:
I don't see why kg as the "SI unit for mass" requires all this prefix_offset stuff. You'd just use pqs::mass:kg, right?
grammes and milligrammes are common units too. The output of socalled coherent quatities is automated so that its not necessary to customise each units ouput. The prefix_offset is necessary to stick the correct prefix on, usually for mass, but also for anything that starts with mass, like 'mass_flow'.
Here's my expectation. Tell me if I'm wrong:
pqs::mass:g grams(10); pqs::mass:kg kilograms(10);
cout << grams << endl; cout << kilograms << endl; cout << kilograms + grams << endl;
I'd expect to see something like this:
10 g 10 kg 10.01 kg
How does this involve prefix_offset at all? What's the point of it? How is mass different than, say, length in this regard?
Try this one: mass::kg m(1); // 1 kg == 1000 g acceleration::m_div_s2 a(1); // 1 meter per second squared force::N f = m * a; The value of f should be 1000 Newtons right? Careful.. its a trick question!
If prefix_offset is not exposed to the user at all, then I submit that it serves no useful function in the library and only makes the implementation (and extensions) unnecessarily difficult.
The output of a quantity is ultimately based on the class template signature. That is what the compiler sees. The prefix offset is necessary to construct and apply the units from that data. Its complicated! As I said before I'm just the messenger ! regards Andy Little
Hi David, "David A. Greene" wrote
I've been waiting in anticipation of pqs for some time. I've had to work with dimensioned values several times and could really have used the compile-time checking pqs offers. It is also, IMHO, one of the best practical examples of template metaprogramming.
- Please always explicitly state in your review, whether you think the library should be accepted into Boost.
I'm disappointed that for now, I would have to reject the library from Boost. I definitely want to see this library make it in but there is one big drawback that's a showstopper for me. Everything is based on powers of 10. More on this below.
There are also some improvements I'd like to see that I don't consider showstoppers. I'll comment on those below as well.
- What is your evaluation of the design?
The everyday user interface is fine. The myriad of concepts and classes to model them can be overwhelming, however. This might be addressed with better documentation.
Yep. I hope I can address that, firstly by changing the layout.
I don't understand the t1_quantity name. It doesn't convey any useful information to me. It needs a better name.
OK. I'm working on it ... !
Unit naming: pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose)
There have been a couple of requests for this. (BTW meter is acceptable by the SI , but metre is not IIRC.) The longer names work ok for units such as meters, but: length::millimeters is quite a handful, while: acceleration::millimeters_div_seconds_squared acc; is a real handful compared with: acceleration::mm_div_s2 acc;
pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have.
The use of 'div' is meant to stand in for 'divided by' as laid down in 'The Guide for the international System of Units' section 7.12. I'm open to changing the rules by which these typedefs are formed, but I would prefer a consensus around one scheme, on grounds that two entities meaning the same thing is never a good idea, also bearing in mind that it needs to be useable over a wide range of various units as shown above.
Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power?
Again if there is a consensus I will add it but I guess I figured that it was redundant. Does it aid comprehensibility? : 1 kg.m^+2.s^-2 If it does I am happy to use it. BTW The output above is that of a so-called 'anonymous quantity'. The concepts of named and anonymous quantities are an answer to a problem that you dont recognise until you start delving into the mysteries of units, namely that two or more quantities can have the same dimension. This happens in the case of torque and energy for example. If assigned to a named_quantity output is sometimes better: 1 kg.m+2.s-2 // anonymous quantity 1 J //energy 1 N.m //torque
Why even have the concept of a prefix_offset? It seems unnecessarily confusing to me. Why does mass default to kg rather than g? If these special cases are really needed, then the documentation needs to explain why. Otherwise, I would prefer that everything work similarly to reduce complexity.
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
The big problem with the design is the assumption that every quantity prefix is based on a power of 10. That's fine for SI units but my hope is that pqs will go beyond just SI. It already does with the incoherent_units so there is some precedent here.
The major issue..
Even before pqs was put up for formal review, I had planned to make use of it in some computer simulator work that I'm doing. The ability to create units like Megabytes and Mibibytes would help tremendously. Unfortunately, I could not figure out how to create a unit that uses prefixes that are powers of 2. It might be ok to "fake" it if the calculations always stayed within one system (Mibibytes, Kibibytes, etc.) but as soon as one wants to convert Mibibytes to Megabytes it falls apart.
OK. Firstly I should point out that bytes and their units arent physical quantities and so according to my self imposed rules re PQS, I ( and the SI) dont cover them under physical quantities. Second as far as I know the binary prefixes arent intended to apply to physical quantities but are only for use in the so-called 'electrotechnology' field.: http://physics.nist.gov/cuu/Units/binary.html Unfortunately I dont know whether the relevent standards bodies have plans to change that or not. However in its raw form , it is possible to use the library to model other entities than physical quantities. The assignment of a particular base dimension to one of the fields in the dimension is arbitrary really and you could use the core of the library for your own purposes. I should show an example of this type of use. The problem is that you need to add all your own functionality and that is the major work. Having said that I will look into how feasible it is to enable the use of alternate units. I could probably tighten the use of base 10 to the particular unit type and uses a traits scheme to allow other bases to be used.
If this can already be done, I'd be overjoyed to be corrected. But I could not puzzle it out from the documentation or a cursory look through the implementation.
No. You are correct. Its hard wired currently.
This is a big gap for me and prevents the use of pqs in most of the day-to-day work that I do.
There's also the question of what base_dimension these would fit under. "Amount of substance?" It would be nice to be able to extend the types of base_dimension but I recognize that this could be very difficult given the design of pqs::meta::dimension and classes that depend on it.
As stated above, once out of the realm of physical quantities its up to you what you assign the base dimensions too. I would guess you would certainly need two base quantities, time and bytes to start with. I could provide the ability to customise the number of available dimension 'slots' via a macro. This might speed compilation for users that regularly only use length, mass, and time for example.
- What is your evaluation of the implementation?
I did not thoroughly review the implementation, just glanced at it to answer some questions. Obviously it does not seem to fulfill my requirements as I stated above. I suspect it will be a bit of work to introduce the new flexibility.
Maybe :-) The primary goal is to stay squarely inside the SI framework and cover that ground comprehensively That is a huge project in itself, however I will see how easy it is to customise the units base.
- What is your evaluation of the documentation?
This needs a lot of work. It seems to assume a deep understanding of SI standards and terminology (beyond the unit names and what they mean) and introduces lots of terms itself (abstract_quantity, named_quantity, concrete_quantity, etc.). The presentation is overwhelming.
As discussed before, I think moving the definition of terms to the back of the docs will go a good way to solve this.
Some specific suggestions:
In the introduction section, we have the following statements about rationale:
Increases programmer satisfaction What does this mean, exactly? It's very vague and subjective.
I guess it is subjective, as its from experience. Before using PQS I remember shuffling back and forth between docs and source files trying to rmemeber what units variable x was in.
enhances productivity How, apart from other rationales given?
Again it saves time because the type rather than docs contains more information. My suggestion would be
to organize the rationale like this:
* Increases programmer satisfaction and enhances productivity. * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Self documenting, helps code clarity.
OK. That sort of makes sense :-)
This is done better in the Rationale section itself. Make the presentation in these two sections similar in structure.
OK.
The ERD was confusing to me. Can this be drawn in UML or a close-to-some-standard way?
OK. I will need to figure that out. My knowledge of UML is pretty much non-existent currently.
Reading through the documentation, one is confronted with the ginormous definitions page almost right away. I'd prefer to see some simple examples of use first. The "Getting started" page is a good start, but would be improved by removing references to the more esoteric terms. Those can come later. The definitions page itself needs many more code examples (for example, for named_quantity). It took me a long time to begin to understand what these terms really mean and I'm still not all the way there yet.
The intent was that the reader would ignore this section after acknowledging it was there. Unfortunately the layout wasnt as I visualised it and the reader obviously doesnt do what I thought they would!
I found the colored links to the terms all over the documentation to be distracting. It really interrupted the flow of the text. It would be better to make these links that look like ordinary text but are highlighted/underlined when the cursor moves over them. The links need to be there but they should be less intrusive.
OK. I would guess that is a CSS issue.
Typos (fixes in brackets):
[t1_quantity features]
The t1_quantity has many similar features to an [a] built-in type...
Where used the type returned by typeof will not[neither] be a reference nor have cv-qualifiers.
[abstract_quantity_id]
The abstract_quantity_id has two roles, the first of which is to distinguish between different but dimensionally_equivalent[ ] abstract_quantities.
[Unary operations example] [c]ondition_true
[Addition and subtraction]
If one type has a coherent_unit and the other has an incoherent_unit the operand with the incoherent_unit will first be converted to a t1_quantity in the nearest coherent_unit( simply found by setting the incoherent_unit[']s[ ]unit_multiplier to 1)
[unit_output_symbol]
A text symbol representing the unit[ ]of a concrete_quantity in stream output.
[Lots of these missing spaces, underscores and first letters of example code through the documentation. Too many to enumerate.]
[Stream output overview]
The output of units for stream output functions for t1_quantities resolves to 3[three] output formats
OK. I will have a good comb through the docs.
- What is your evaluation of the potential usefulness of the library?
Very. IMHO strong typing is essential when designing large systems.
- Did you try to use the library? With what compiler? Did you have any problems?
I was going to do some experiments to create my own quantities as described above, but I could not figure out how to do it, so I did not do any testing.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
In-depth reading of the documentation with a clear idea of how I wanted to extend the framework. Unfortunately, I discovered that I could not do what I'd hoped to accomplish.
- Are you knowledgeable about the problem domain?
In the same way most scientists and engineers are. I'm certainly no authority on the formal SI standards. I do have a large amount of experience in computer simulation and have run into the need for this kind of package for "computer units" over and over. It would be nice to have a package that went beyond the SI and its rigid assumptions.
I will look into the possibility of customising base used by units and see if I can provide an example of using the library outside the SI. Thanks for the review. regards Andy Little
Andy Little wrote:
pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose)
There have been a couple of requests for this. (BTW meter is acceptable by the SI , but metre is not IIRC.) The longer names work ok for units such as meters, but:
length::millimeters
is quite a handful, while:
acceleration::millimeters_div_seconds_squared acc;
is a real handful compared with:
acceleration::mm_div_s2 acc;
Sure, this is a matter of taste. I think for the base units it should be fine, though.
pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have.
The use of 'div' is meant to stand in for 'divided by' as laid down in 'The Guide for the international System of Units' section 7.12.
I'm open to changing the rules by which these typedefs are formed, but I would prefer a consensus around one scheme, on grounds that two entities meaning the same thing is never a good idea, also bearing in mind that it needs to be useable over a wide range of various units as shown above.
I don't see why two entities with the same meaning is necessarily a problem. That's the whole point of typedefs. If the community agrees that one interface is best, I'm find with "div" due to the official SI recommendtation.
Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power?
Again if there is a consensus I will add it but I guess I figured that it was redundant. Does it aid comprehensibility? :
1 kg.m^+2.s^-2
If it does I am happy to use it.
Getting rid of the "+" would help: 1 kg.m^2.s^-2 Or better yet: 1 kg.m^2/s^2 But the latter will get you into all sorts of complexity wrt parentheses, etc.
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
But I don't understand why the SI "interface" commands a particular pqs implementation. From the user perspective, they don't really care. But as soon as a programmer tries to extend the framework, nightmares ensue. Perhaps I'm just not understanding something very fundamental and basic.
Even before pqs was put up for formal review, I had planned to make use of it in some computer simulator work that I'm doing. The ability to create units like Megabytes and Mibibytes would help tremendously. Unfortunately, I could not figure out how to create a unit that uses prefixes that are powers of 2. It might be ok to "fake" it if the calculations always stayed within one system (Mibibytes, Kibibytes, etc.) but as soon as one wants to convert Mibibytes to Megabytes it falls apart.
OK. Firstly I should point out that bytes and their units arent physical quantities and so according to my self imposed rules re PQS, I ( and the SI) dont cover them under physical quantities. Second as far as I know the binary prefixes arent intended to apply to physical quantities but are only for use in the so-called 'electrotechnology' field.:
http://physics.nist.gov/cuu/Units/binary.html
Unfortunately I dont know whether the relevent standards bodies have plans to change that or not.
I think restricting the library to "physical quantities" is a big mistake. You've put a _lot_ of effort into getting the metaprogramming right for his and we ought to try to re-use it wherever possible. I don't relish the idea of creating a parallel "electrotechnology system" framework that looks exactly like pqs but with powers of 2 and 10 (to do the conversions). Let's get it right in a single library.
However in its raw form , it is possible to use the library to model other entities than physical quantities. The assignment of a particular base dimension to one of the fields in the dimension is arbitrary really and you could use the core of the library for your own purposes. I should show an example of this type of use. The problem is that you need to add all your own functionality and that is the major work.
How would this added functionality interact with the power-of-10 framework? The big issue is converting between a system that uses powers-of-10 and some other system (powers-of-2 in my case).
Having said that I will look into how feasible it is to enable the use of alternate units. I could probably tighten the use of base 10 to the particular unit type and uses a traits scheme to allow other bases to be used.
That would be great. It will be necessary to allow conversions between powers-of-2 and powers-of-10.
As stated above, once out of the realm of physical quantities its up to you what you assign the base dimensions too. I would guess you would certainly need two base quantities, time and bytes to start with.
Right. And conversions.
I could provide the ability to customise the number of available dimension 'slots' via a macro. This might speed compilation for users that regularly only use length, mass, and time for example.
I was thinking along those lines as well. -Dave
"David Greene" wrote
Andy Little wrote:
David Greene wrote
pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose)
There have been a couple of requests for this. (BTW meter is acceptable by the SI , but metre is not IIRC.) The longer names work ok for units such as meters, but:
length::millimeters
is quite a handful, while:
acceleration::millimeters_div_seconds_squared acc;
is a real handful compared with:
acceleration::mm_div_s2 acc;
Sure, this is a matter of taste. I think for the base units it should be fine, though.
The problem is to get something that works well for all units, is easy to remember, has a consistent formula and is concise. When I am writing source code, I am not worried about whether a quantity is a base unit or not. I need to be able to figure out its name quickly and write it quickly too.
pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have.
The use of 'div' is meant to stand in for 'divided by' as laid down in 'The Guide for the international System of Units' section 7.12.
I'm open to changing the rules by which these typedefs are formed, but I would prefer a consensus around one scheme, on grounds that two entities meaning the same thing is never a good idea, also bearing in mind that it needs to be useable over a wide range of various units as shown above.
I don't see why two entities with the same meaning is necessarily a problem. That's the whole point of typedefs. If the community agrees that one interface is best, I'm find with "div" due to the official SI recommendtation.
IMO if you have two names for something its because the first was a mistake for some reason.
Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power?
Again if there is a consensus I will add it but I guess I figured that it was redundant. Does it aid comprehensibility? :
1 kg.m^+2.s^-2
If it does I am happy to use it.
Getting rid of the "+" would help:
1 kg.m^2.s^-2
Again, if its preferred enough then I'll modify it. I should point out that ideally you wont get these format output anyway, because you assign everything to a so called named_quantity, FWIW, which should have prettier custom output. In practise its unlikely you will be serialising anonymous quantities. ( because you are usually not serialising temporaries) IOW anonymous quantities are a bit ugly, the output format reflects that.
Or better yet:
1 kg.m^2/s^2
But the latter will get you into all sorts of complexity wrt parentheses, etc.
Yep!. The dots work quite well as separators and again the format is based on the recommended useage in the SI manual which uses dots.
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
But I don't understand why the SI "interface" commands a particular pqs implementation. From the user perspective, they don't really care. But as soon as a programmer tries to extend the framework, nightmares ensue.
I dont think electrotechnology is an extension to the SI. IMO its a different system in which bytes and time exists, but not mass, length, current etc etc. regards Andy Little
Andy Little wrote:
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
But I don't understand why the SI "interface" commands a particular pqs implementation. From the user perspective, they don't really care. But as soon as a programmer tries to extend the framework, nightmares ensue.
I dont think electrotechnology is an extension to the SI. IMO its a different system in which bytes and time exists, but not mass, length, current etc etc.
We're not talking about Mibibytes here. My question is, why does someone extending the "mass" abstract quantity (is that the correct term?) need to worry about prefix_offset? Why isn't "kilo" specified with "3" like it is everywhere else? AFAICT this has no impact on the user interface. The user will just specify pqs::mass::kg and doesn't care what the underlying "prefix number" is. But this change makes the framework extender's job much easier. -Dave
"David Greene" <greened@obbligato.org> wrote in message news:44873FB6.6020709@obbligato.org...
Andy Little wrote:
The kilogram rather than the gramme is a base unit in the SI. I think that the history has to do with the emergence of the SI system from the C.G.S system. Presumably they decided that the gramme from the C.G.S system was too small a unit, the mystery then being why C.G.S used centimeters in the first place. Whatever. I agree the whole thing is a logicians nightmare. I'm just the messenger...
But I don't understand why the SI "interface" commands a particular pqs implementation. From the user perspective, they don't really care. But as soon as a programmer tries to extend the framework, nightmares ensue.
I dont think electrotechnology is an extension to the SI. IMO its a different system in which bytes and time exists, but not mass, length, current etc etc.
We're not talking about Mibibytes here. My question is, why does someone extending the "mass" abstract quantity (is that the correct term?) need to worry about prefix_offset? Why isn't "kilo" specified with "3" like it is everywhere else?
kilogram is an si base_unit. In pqs base units are represented in compile time code by the boost:pqs::meta::unit in header <boost/pqs/meta/unit.hpp> The unit consists in two parts used for calculation, and an id whose purpose is irrelevent here. The two parts of the unit used in unit conversions are the exponent and the multiplier, both represeneted as compile time constants For coherent units the multiplier is one. The kilogram is a coherent unit so we can also ignore that. The exponent is the power of 10 by which the base unit is multiplied to get the unit. If kilograms played by the rules its exponent would be 3 , but for whatever historical reasons its 0. The output for named quantities with coherent units is computed at compile time from the class template signature. For those interested this is in: <boost/pqs/meta/components/adjusted_coherent_prefix.hpp> Without the prefix_offset, because kilograms has an exponent of 0, then its unit output would be worked out as 'g', which is plainly wrong. Does this help?
AFAICT this has no impact on the user interface. The user will just specify pqs::mass::kg and doesn't care what the underlying "prefix number" is. But this change makes the framework extender's job much easier.
Complain to the SI people. It aint my fault guvnor! regards Andy Little
On Thu, Jun 08, 2006 at 08:49:41AM +0100, Andy Little wrote:
The exponent is the power of 10 by which the base unit is multiplied to get the unit.
If kilograms played by the rules its exponent would be 3 , but for whatever historical reasons its 0.
I think it's logical to use 0, too. Not just logical, definitely the most logical thing. Carlo "Spock" Wood
Andy Little wrote:
If kilograms played by the rules its exponent would be 3 , but for whatever historical reasons its 0.
Why is "some historicasl reason" which we can't seem to puzzle out driving the implementation of the library?
The output for named quantities with coherent units is computed at compile time from the class template signature. For those interested this is in: <boost/pqs/meta/components/adjusted_coherent_prefix.hpp>
Without the prefix_offset, because kilograms has an exponent of 0, then its unit output would be worked out as 'g', which is plainly wrong.
Does this help?
Why not just give kg anb exponent of "3" like everywhere else and then adjust the other mass exponents accordingly. Why special-case this?
AFAICT this has no impact on the user interface. The user will just specify pqs::mass::kg and doesn't care what the underlying "prefix number" is. But this change makes the framework extender's job much easier.
Complain to the SI people. It aint my fault guvnor!
But it's your library! Honestly, I think you are too constrained by some paper SI standard. There is nothing at all that says the library must be implemented this way. -Dave
On 2006-06-08, David Greene <greened@obbligato.org> wrote:
Complain to the SI people. It aint my fault guvnor! But it's your library! Honestly, I think you are too constrained by some paper SI standard. There is nothing at all that says
Andy Little wrote: the library must be implemented this way.
The SI standard has been agreed to be implemented worldwide (and should already be according to the original intention). Including the USA and the UK (both dragging their feet). It isn't just *some* standard - it is *the* standard. Of course, the Boost units standard might someday supplant it, but, really, I doubt it. phil -- change name before "@" to "phil" for email
Phil Richards wrote:
On 2006-06-08, David Greene <greened@obbligato.org> wrote:
Andy Little wrote:
Complain to the SI people. It aint my fault guvnor!
But it's your library! Honestly, I think you are too constrained by some paper SI standard. There is nothing at all that says the library must be implemented this way.
The SI standard has been agreed to be implemented worldwide (and should already be according to the original intention). Including the USA and the UK (both dragging their feet). It isn't just *some* standard - it is *the* standard. Of course, the Boost units standard might someday supplant it, but, really, I doubt it.
But that doesn't have anything to do with the _implementation_ of the library. Andy presented this example to justify kg's 0 power: mass::kg m(1); // 1 kg == 1000 g acceleration::m_div_s2 a(1); // 1 meter per second squared force::N f = m * a; The value of f should be 1000 Newtons right? Of course, the value is 1 Newton. But this has nothing at all to do with kg having a prefix power of 0 or 3. The calculation can be done when assigning m*a to f. The compiler (though TMP techniques) knows that m*a is in kg*m/s^2. It knows it's being assigned to a value of N. It can look up the prefix powers (3 for kg in my suggestion) and "do the right thing." If that requires some special cases for conversions like this, it's better than forcing everyone who extends the system to keep track of which quantities follow the rules and which don't. And besides, as others have argued, a Boost units library needs to go beyond S.I. S.I. is far too narrow for many domains. -Dave
On Thu, Jun 08, 2006 at 05:36:40PM -0500, David Greene wrote:
the library. Andy presented this example to justify kg's 0 power:
mass::kg m(1); // 1 kg == 1000 g acceleration::m_div_s2 a(1); // 1 meter per second squared force::N f = m * a;
The value of f should be 1000 Newtons right?
Of course, the value is 1 Newton. But this has nothing at all to do with kg having a prefix power of 0 or 3. The calculation can
The point is, 1 N = 1 kg * 1 m / 1 s / 1 s The 1 comes from 10^0, hence 0 is needed. 10^0 N = 10^0 kg * 10^0 m / 10^0 s / 10^0 s 0 = 0 + 0 - 0 - 0 The calculation of the left-hand 0 is done with generic templates using '+' to add up exponents. How is it logical to make an exception here for kg? If you'd force 'kg' to be 'g' internally, then you will have to apply the same trick to N that is now applied to kg, with the exception that then BOTH are internally not in S.I. units (mN and g, instead of N and kg). That is, you'd end up with: 3 = 3 + 0 - 0 - 0 and thus mN. But you still want to print N. I don't think it will get any better by using a prefix power of 3 for kg. -- Carlo Wood <carlo@alinoe.com>
I'm glad to see all the interest this library is gaining! David Greene <greened <at> obbligato.org> writes:
Andy Little wrote:
acceleration::millimeters_div_seconds_squared acc;
is a real handful compared with:
acceleration::mm_div_s2 acc;
FWIW, in my implementation I just used: acceleration acc = 10.0 * millimeter / sqr(second); and lived with the extra divide and multiplies - again assuming the overhead is low because most of my code is doing computations on these variables once the values have been assigned. Getting the numeric input values in is just a small part of the processing time in my application. If this is not true for other people, perhaps there's a way to maintain the sort of syntax above yet avoid the extra arithmetic using template metaprogramming - I haven't thought it through.
The ability to create units like Megabytes and Mibibytes would help tremendously.
OK. Firstly I should point out that bytes and their units arent physical quantities and so according to my self imposed rules re PQS, I ( and the SI) dont cover them under physical quantities.
I think restricting the library to "physical quantities" is a big mistake. You've put a _lot_ of effort into getting the metaprogramming right for his and we ought to try to re-use it wherever possible. I don't relish the idea of creating a parallel "electrotechnology system" framework that looks exactly like pqs but with powers of 2 and 10 (to do the conversions). Let's get it right in a single library.
Several reviewers have made comments to this effect. It seems there is a need in a variety of non-physics contexts as well for a general units conversion library. However, IMHO, PQS is *not* a units library. Its purpose is to do dimensional analysis. For this reason (as well as a weaker one I mentioned in another followup post), I oppose the name "units" for the library. That would only add to the confusion. Units conversion is a necessary part of the library (or adjuct to it) in order to create the dimensional quantities, but the core purpose and utility of the library is its compile-time checking of dimensional formulas and enforced documentation of dimensions (as well as units). Perhaps, as Gerhard Wesp suggested in one of his posts (sorry, I don't know how to include a message reference):
I think that handling of dimensional quantities and conversion factors are orthogonal concepts and should be separated.
If there's a way to do this, perhaps the units conversion can be made more general and put into a separate library, and the dimensional analysis library can make use of it. But please, let's not lose sight of the great importance of a dimensional analysis library. Many users (though perhaps a minority) find this *very* useful.
I could provide the ability to customise the number of available dimension 'slots' via a macro. This might speed compilation for users that regularly only use length, mass, and time for example.
I was thinking along those lines as well.
Not a bad idea. In my implementation, in fact, we only needed length and time dimensions, since the masses effectively cancel out of all our motion equations, and only integer exponents, so I coded it in this limited form. -- Leland
Leland Brown wrote:
I think restricting the library to "physical quantities" is a big mistake. You've put a _lot_ of effort into getting the metaprogramming right for his and we ought to try to re-use it wherever possible. I don't relish the idea of creating a parallel "electrotechnology system" framework that looks exactly like pqs but with powers of 2 and 10 (to do the conversions). Let's get it right in a single library.
Several reviewers have made comments to this effect. It seems there is a need in a variety of non-physics contexts as well for a general units conversion library.
However, IMHO, PQS is *not* a units library. Its purpose is to do dimensional analysis. For this reason (as well as a weaker one I mentioned in another followup post), I oppose the name "units" for the library. That would only add to the confusion. Units conversion is a necessary part of the library (or adjuct to it) in order to create the dimensional quantities, but the core purpose and utility of the library is its compile-time checking of dimensional formulas and enforced documentation of dimensions (as well as units).
The two go hand-in-hand. What good is a "units" library without dimensional analysis? All I'm saying is that we should not need to create multiple versions of pqs to handle different sets of units. Where does it stop? I want one for "electrotechnology." Someone else wants one for non-SI units. Someone gave an example of dimensioning fruits and vegetables. Do we really want separate frameworks for each of these uses? It should all be in one framework. I'm not saying everything needs to be implemented right now. Just that the flexibility needs to be there for _someone_ to do it. The assumption of powers-of-10 prefixes precludes that.
Perhaps, as Gerhard Wesp suggested in one of his posts (sorry, I don't know how to include a message reference):
I think that handling of dimensional quantities and conversion factors are orthogonal concepts and should be separated.
If there's a way to do this, perhaps the units conversion can be made more general and put into a separate library, and the dimensional analysis library can make use of it. But please, let's not lose sight of the great importance of a dimensional analysis library. Many users (though perhaps a minority) find this *very* useful.
As Andy has stated, the two are orthogonal in pqs, it's just that metaprogramming is used to encode the conversions in the type system, thereby saving runtime calculation by doing it at compile time. This is the correct approach, because for t1_quantity, all of the necessary information is known by the compiler. -Dave
Andy Little wrote:
Hi David,
"David A. Greene" wrote
pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have.
The use of 'div' is meant to stand in for 'divided by' as laid down in 'The Guide for the international System of Units' section 7.12.
I'm open to changing the rules by which these typedefs are formed, but I would prefer a consensus around one scheme, on grounds that two entities meaning the same thing is never a good idea, also bearing in mind that it needs to be useable over a wide range of various units as shown above.
I find m_per_s much more readable than m_div_s, but as a native English speaker, both 'per' and 'div' make sense to me. Before stating categorically that 'per' is preferable, I'd like like to hear from non-native speakers. They might be comfortable with 'div' but completely confused by 'per'.
Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power?
Again if there is a consensus I will add it but I guess I figured that it was redundant. Does it aid comprehensibility? :
1 kg.m^+2.s^-2
If it does I am happy to use it.
For me, the real bar to comprehensibility is the signs on the exponents. When I see kg.m+2.s-2, I read it as kg-dot-m plus 2-dot-s minus 2. If it could it be written like this: kg.m2_div_s2 it would be much clearer.
- What is your evaluation of the documentation?
This needs a lot of work. It seems to assume a deep understanding of SI standards and terminology (beyond the unit names and what they mean) and introduces lots of terms itself (abstract_quantity, named_quantity, concrete_quantity, etc.). The presentation is overwhelming.
As discussed before, I think moving the definition of terms to the back of the docs will go a good way to solve this.
I disagree. First, David's criticism ("It seems to assume a deep understanding of SI standards and terminology") doesn't apply only to the glossary. You can't get through the first paragraph of "Basic Useage", (shouldn't that be "Usage"?) without encountering "t1_quantity specification", "concrete_quantities", and "named_quantity". These terms are going to send a lot of people straight to the definitions page wherever it's located. Those concepts may be necessary for a complete understanding of pqs, but I suspect that someone could use the library in a simple implementation without knowing much about them. If that's true, they should also be able to read the basic usage section without encountering that terminology. It might also be helpful to have a "Physical Quantities Concepts" page, with a concrete example of some object or system which would illustrate the terms. This would familiarize readers with the necessary terminology in a straightforward, easily comprehensible way, reducing their reliance on the definitions page. Second, the definitions themselves are sometimes rough going. Dimension, for example, is defined like this: "The dimension of a physical_quantity is comprised of the powers of each of its base_dimensions." Physical_quantity quantity is defined as "A measurable physical phenomenon," and base_dimension as "A simple, measurable and essentially irreducible physical phenomenon." This means that base_dimension is really a simple and essentially irreducible physical_quantity (i.e. a base physical_quantity) which suggests that 'physical_quantity' and 'dimension' are interchangeable, but the definition of dimension suggests that it's an attribute of physical_quantity having to do with powers. Even after browsing most of the documentation, including the definitions page, I still don't really understand the distinction between dimensions and physical quantities. The definitions page also describes coherent_unit as "essentially units designed as part of the SI", and incoherent_unit as "essentially a unit outside the SI." That being the case, why not just use SI and non-SI, in place of coherent, and incoherent?
I found the colored links to the terms all over the documentation to be distracting. It really interrupted the flow of the text. It would be better to make these links that look like ordinary text but are highlighted/underlined when the cursor moves over them. The links need to be there but they should be less intrusive.
OK. I would guess that is a CSS issue.
I'm not convinced they really do need to be there. The BGL doc, for example, has an introductory section explaining terms like vertex, edge, etc., and then uses those terms throughout, without links to definitions. If the pqs doc did the same, at least with basic terms like 'dimensions', 'units', etc, it would reduce the number of links enormously. It might be nice to have a standard definition-link style in the Boost CSS anyway, but I don't think that's essential.
My suggestion would be to organize the rationale like this:
* Increases programmer satisfaction and enhances productivity. * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Self documenting, helps code clarity.
I'd leave off the first sentence altogether. When I read that pqs catches errors, eliminates the need for tedious (and error-prone) explicit conversions, and improves code clarity, I immediately recognize those as Very Good Things. I don't need the docs to tell me I'll be more satisfied and productive as a result. A few more observations: The "Introduction to pqs" page is not very helpful. The first thing I want a library doc to tell me is what the library does and whether it's worth investigating further. The introduction instead starts out with an "Overview", which mostly talks about what pqs will eventually do in the future. While interesting, that doesn't really belong in the introduction. I'd much rather see something like the 'Description' section of Fred Bertsch's review announcement post: "PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications." From just that one paragraph I've already got a pretty good idea about whether pqs is going to be useful to me. A tutorial with a simplified real-world example of a pqs-enabled program would also be very helpful. The "Getting started" page contains a lot of code snippets but most of them illustrate only declarations and simple operations. I realize that encompasses most of what pqs does, but it would still be nice to see them in different contexts, e.g. std containers of physical quantities, functions with physical quantities as parameters, etc. I'd particularly like to see an example of pqs interoperating with boost.date_time. They'll be a natural combination for many applications, so it would be nice to see code that converts between them.
"Beth Jacobson" wrote: [ per vs div ]
I find m_per_s much more readable than m_div_s, but as a native English speaker, both 'per' and 'div' make sense to me. Before stating categorically that 'per' is preferable, I'd like like to hear from non-native speakers. They might be comfortable with 'div' but completely confused by 'per'.
per (http://en.wiktionary.org/wiki/per), coming from Latin is somehow familiar in European languages. It is understood and occasionally used in Czech, for example. Having typedefs for typically used names would avoid this kind of discussion. /Pavel
Beth Jacobson said: (by the date of Wed, 07 Jun 2006 15:13:05 -0400)
I find m_per_s much more readable than m_div_s, but as a native English speaker, both 'per' and 'div' make sense to me. Before stating categorically that 'per' is preferable, I'd like like to hear from non-native speakers. They might be comfortable with 'div' but completely confused by 'per'.
Even in my native language, polish, it is possible to use both versions "div" and "per" (in polish it's "metr przez sekunde" ("div") and "metr na sekunde" ("per") ). The "div" version sounds kind of more mathematical (in polish), while the "per" version is more widely used. As non-native speaker I'd prefer "per". BUT we must understand implications of this: more complicated units are weird to express using "per", so this notation makes sense only to apply to the simple division with single numerator component and single denominator. OTOH having typedefs with "per" only for few selected variants makes them _special_ and you have to list them in the docs, or somewhere. Much hassle, small gain. Maybe it's better to do one of following: - use only "div" or - use "div" and "per" fully interchangeably. Make typedefs for everything. Then in manual write: "Internal notation uses 'div' as a divisor word, but typedefs are additionally defined for all of them with 'per' as a divisor word, so the user can choose whichever one is preferred". The hassle here is just one extra sentence in the manual. Personally I'd prefer the second option. -----------------------------------------------------
kg.m2_div_s2
it would be much clearer.
I've been wondering why not use * like this: kg*m^2*s^-2 or this: kg*m^2/s^2 Are * and / restricted, being ,,special'' characters? -----------------------------------------------------
"Basic Useage", (shouldn't that be "Usage"?)
I was wondering that maybe it's some variant of english... maybe canadian english? I don't know. But I'm sure that the word 'useage' is for me weird - and maybe it'd be better to use more popular variants of english, and write 'usage' and 'using'. (I'm sorry about being a bit offtopic here)
why not just use SI and non-SI, in place of coherent, and incoherent?
good point.
I'd much rather see something like the 'Description' section of Fred Bertsch's review announcement post:
"PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications."
From just that one paragraph I've already got a pretty good idea about whether pqs is going to be useful to me.
I second that.
A tutorial with a simplified real-world example of a pqs-enabled program would also be very helpful. The "Getting started" page contains a lot of code snippets but most of them illustrate only declarations and simple operations. I realize that encompasses most of what pqs does, but it would still be nice to see them in different contexts, e.g. std containers of physical quantities, functions with physical quantities as parameters, etc. I'd particularly like to see an example of pqs interoperating with boost.date_time. They'll be a natural combination for many applications, so it would be nice to see code that converts between them.
good idea. Also few short examples that you could just copy'n'paste from the manual to the editor and compile them, whould be nice. Even though there are many files in the examples directory - people first look into docs, later they browse directory structure to find examples (and its more tiresome - copy'n'paste from the documentation is plain easier. -- Janek Kozicki |
"Janek Kozicki" wrote
Personally I'd prefer the second option.
-----------------------------------------------------
kg.m2_div_s2
it would be much clearer.
I've been wondering why not use * like this:
kg*m^2*s^-2
or this:
kg*m^2/s^2
Are * and / restricted, being ,,special'' characters?
I must admit that both the ouput format and the quantity typedef names, I frankly havent done much work on, beyond getting something that works. I would welcome help from anyone regarding writing a specification in both areas. In the output area one think lacking is going beyond ASCII. It would be nice to output Ohms as Ω rather than R for example. Any help with that would be appreciated too. I dont really know where to start with that. regards Andy Little
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 08 June 2006 11:39 | To: boost@lists.boost.org | Subject: Re: [boost] [review] pqs | In the output area one think lacking is going beyond ASCII. | It would be nice to output Ohms as O rather than R for example. | Any help with that would be appreciated too. It all goes back to 8 hole paper tape - where one hole was misguidedly reserved for parity. One of the Great Computing Disasters :-(( (Thankfully, magnetic 1/2 inch tape was made 9 track, or we would have 7 bits per byte). Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Hi Paul, "Paul A Bristow" wrote
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 08 June 2006 11:39 | To: boost@lists.boost.org | Subject: Re: [boost] [review] pqs
| In the output area one think lacking is going beyond ASCII. | It would be nice to output Ohms as O rather than R for example. | Any help with that would be appreciated too.
It all goes back to 8 hole paper tape - where one hole was misguidedly reserved for parity.
One of the Great Computing Disasters :-((
(Thankfully, magnetic 1/2 inch tape was made 9 track, or we would have 7 bits per byte).
We havent moved on much! Your post is particularly amusing because the sentence including the text " Ohms as O" in your reply has been magically transformed in the round trip. What has been returned to me as a Capital O was sent as the electronic symbol for ohms at considerable trouble. I went in to MS Word, selected the ohms symbol and pasted it in, with some sort of vague hope that it might survive the trip. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e68uok$agd$1@sea.gmane.org...
"Janek Kozicki" wrote
Personally I'd prefer the second option.
-----------------------------------------------------
kg.m2_div_s2
it would be much clearer.
I've been wondering why not use * like this:
kg*m^2*s^-2
or this:
kg*m^2/s^2
Are * and / restricted, being ,,special'' characters?
I must admit that both the ouput format and the quantity typedef names, I frankly havent done much work on, beyond getting something that works. I would welcome help from anyone regarding writing a specification in both areas.
In the output area one think lacking is going beyond ASCII. It would be nice to output Ohms as Ω rather than R for example. Any help with that would be appreciated too. I dont really know where to start with that.
BTW whatever appears locally after " output Ohms as " is meant to be the electronic symbol for Ohms. I suspect that its not the case though! regards Andy Little
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
I must admit that both the ouput format and the quantity typedef names, I frankly havent done much work on, beyond getting something that works. I would welcome help from anyone regarding writing a specification in both areas.
In the output area one think lacking is going beyond ASCII. It would be nice to output Ohms as Ω rather than R for example. Any help with that would be appreciated too. I dont really know where to start with that.
Why not facets pqs_put, pqs_get, pqs_punct pqs_punct could contain members like virtual string multiplication() const { return ""; } virtual string division() const { return "/"; } virtual string power() const { return "^"; } virtual string greeksymbol(some enum) const { ... } If you want to use other separators or symbols, just create your own pqs_facet. If you want to format the units in a completly different way (e.g. multiple lines), create your own pqs_put facet.
Andy Little wrote:
In the output area one think lacking is going beyond ASCII. It would be nice to output Ohms as Ω rather than R for example. Any help with that would be appreciated too. I dont really know where to start with that.
That would be neat. My sense is that they'll need to be some kind of trait or property that controls character encoding. I'm not at all familiar with i18n or l10n issues, so I'll leave that to the experts. I'd definitely want to have the option of using plain 'ol ASCII becausde not all terminals support things like unicode. -Dave
"Beth Jacobson" wrote
Andy Little wrote:
Hi David,
"David A. Greene" wrote For me, the real bar to comprehensibility is the signs on the exponents. When I see kg.m+2.s-2, I read it as kg-dot-m plus 2-dot-s minus 2. If it could it be written like this:
kg.m2_div_s2
it would be much clearer.
The use of dots and signs is again based on the SI. See for example section 6.1.6 in the 'Guide for the use of the International System of Units'. The +ve sign is redundant but I liked the symmetry and it felt better that leaving it out. and IMO underbars are overused in C++ already.
- What is your evaluation of the documentation?
This needs a lot of work. It seems to assume a deep understanding of SI standards and terminology (beyond the unit names and what they mean) and introduces lots of terms itself (abstract_quantity, named_quantity, concrete_quantity, etc.). The presentation is overwhelming.
As discussed before, I think moving the definition of terms to the back of the docs will go a good way to solve this.
I disagree. First, David's criticism ("It seems to assume a deep understanding of SI standards and terminology") doesn't apply only to the glossary. You can't get through the first paragraph of "Basic Useage", (shouldn't that be "Usage"?) without encountering "t1_quantity specification", "concrete_quantities", and "named_quantity". These terms are going to send a lot of people straight to the definitions page wherever it's located. Those concepts may be necessary for a complete understanding of pqs, but I suspect that someone could use the library in a simple implementation without knowing much about them. If that's true, they should also be able to read the basic usage section without encountering that terminology. It might also be helpful to have a "Physical Quantities Concepts" page, with a concrete example of some object or system which would illustrate the terms. This would familiarize readers with the necessary terminology in a straightforward, easily comprehensible way, reducing their reliance on the definitions page.
Second, the definitions themselves are sometimes rough going. Dimension, for example, is defined like this: "The dimension of a physical_quantity is comprised of the powers of each of its base_dimensions." Physical_quantity quantity is defined as "A measurable physical phenomenon," and base_dimension as "A simple, measurable and essentially irreducible physical phenomenon." This means that base_dimension is really a simple and essentially irreducible physical_quantity (i.e. a base physical_quantity) which suggests that 'physical_quantity' and 'dimension' are interchangeable, but the definition of dimension suggests that it's an attribute of physical_quantity having to do with powers. Even after browsing most of the documentation, including the definitions page, I still don't really understand the distinction between dimensions and physical quantities.
The definitions page also describes coherent_unit as "essentially units designed as part of the SI", and incoherent_unit as "essentially a unit outside the SI." That being the case, why not just use SI and non-SI, in place of coherent, and incoherent?
The whole definitions section is obviously problematic. Originally the entities reffered to appeared out of the bottom-up style the library was written in. Trying to explain them to anyone else is not my forte. It is difficult to describe the semantics without them however. I wonder if the library can claim to have the most complicated operation semantics of any C++ library in existence!
I found the colored links to the terms all over the documentation to be distracting. It really interrupted the flow of the text. It would be better to make these links that look like ordinary text but are highlighted/underlined when the cursor moves over them. The links need to be there but they should be less intrusive.
OK. I would guess that is a CSS issue.
I'm not convinced they really do need to be there. The BGL doc, for example, has an introductory section explaining terms like vertex, edge, etc., and then uses those terms throughout, without links to definitions. If the pqs doc did the same, at least with basic terms like 'dimensions', 'units', etc, it would reduce the number of links enormously. It might be nice to have a standard definition-link style in the Boost CSS anyway, but I don't think that's essential.
Its worth experimenting with surely.
My suggestion would be to organize the rationale like this:
* Increases programmer satisfaction and enhances productivity. * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Self documenting, helps code clarity.
I'd leave off the first sentence altogether. When I read that pqs catches errors, eliminates the need for tedious (and error-prone) explicit conversions, and improves code clarity, I immediately recognize those as Very Good Things. I don't need the docs to tell me I'll be more satisfied and productive as a result.
OK.
A few more observations:
The "Introduction to pqs" page is not very helpful. The first thing I want a library doc to tell me is what the library does and whether it's worth investigating further. The introduction instead starts out with an "Overview", which mostly talks about what pqs will eventually do in the future. While interesting, that doesn't really belong in the introduction. I'd much rather see something like the 'Description' section of Fred Bertsch's review announcement post:
"PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications."
From just that one paragraph I've already got a pretty good idea about whether pqs is going to be useful to me.
OK.
A tutorial with a simplified real-world example of a pqs-enabled program would also be very helpful. The "Getting started" page contains a lot of code snippets but most of them illustrate only declarations and simple operations. I realize that encompasses most of what pqs does, but it would still be nice to see them in different contexts, e.g. std containers of physical quantities, functions with physical quantities as parameters, etc. I'd particularly like to see an example of pqs interoperating with boost.date_time. They'll be a natural combination for many applications, so it would be nice to see code that converts between them.
OK. I will try to incorporate some bigger examples. Thanks for the comments. regards Andy Little
Andy Little wrote:
The use of dots and signs is again based on the SI. See for example section 6.1.6 in the 'Guide for the use of the International System of Units'. The +ve sign is redundant but I liked the symmetry and it felt better that leaving it out. and IMO underbars are overused in C++ already.
Here's an example of where a rigid specification (SI) is degrading the user experience. Picking an output format just because the SI says it is the one to use is a mistake. If the Boost community decides it's the right format, then it's the right format. But to preclude changes because it may contradict the formal SI standard seems shortsighted. I don't mind the dots. I could live with "*" as well. But I really don't like "+." I also tend to interpret it as signifying addition, not a sign value on an exponent. Using ^ or ** would help with that. -Dave
David Greene wrote:
Andy Little wrote:
The use of dots and signs is again based on the SI. See for example section 6.1.6 in the 'Guide for the use of the International System of Units'. The +ve sign is redundant but I liked the symmetry and it felt better that leaving it out. and IMO underbars are overused in C++ already.
Here's an example of where a rigid specification (SI) is degrading the user experience.
This is a little broad a claim. It might be degrading your user experience.
Picking an output format just because the SI says it is the one to use is a mistake.
In my book ignoring an existing standard just because we think we can come up with a better idea within 2 hours is a mistake and at least a little arrogant for that matter.
If the Boost community decides it's the right format, then it's the right format. But to preclude changes because it may contradict the formal SI standard seems shortsighted.
Precluding them is stubborn. But having anything but a very high threshold for deviating from existing standards is asking for trouble, to put it politely. Nothing I've seen so far comes anywhere near that threshold. An example for something that makes it would be that the respective part of the standard is commonly known as broken. I think that Andy made a very good choice in following existing standards. Thomas -- Thomas Witt witt@acm.org
On Wed, Jun 07, 2006 at 03:13:05PM -0400, Beth Jacobson wrote:
I find m_per_s much more readable than m_div_s, but as a native English speaker, both 'per' and 'div' make sense to me. Before stating categorically that 'per' is preferable, I'd like like to hear from non-native speakers. They might be comfortable with 'div' but completely confused by 'per'.
English: meter per second Dutch: meter per seconde French: mètres par seconde German: meter pro sekunde Spanish: metro por segundo I think that 'per' is as much english as 'divided by'. People who know english won't be confused by it. -- Carlo Wood <carlo@alinoe.com>
"Deane Yang" wrote Carlo Wood wrote:
English: meter per second Dutch: meter per seconde French: mtres par seconde German: meter pro sekunde Spanish: metro por segundo
I think that 'per' is as much english as 'divided by'. People who know english won't be confused by it.
I also vote for "per".
in this case, as typedefs for declaring a quantity of a particular type , you end up with velocity:: m_per_s velocity:: mi_per_h acceleration::m_per_s2; reciprocal_time::per_s; reciprocal_mass::per_kg; mass_flow::kg_per_s; It might even be possible to abbreviate it and keep the sense: velocity:: m_p_s velocity:: mi_p_h acceleration::m_p_s2; reciprocal_time::p_s; reciprocal_mass::p_kg; mass_flow::kg_p_s; FWIW regards Andy Little
"Deane Yang" wrote Carlo Wood wrote:
English: meter per second Dutch: meter per seconde French: mtres par seconde German: meter pro sekunde Spanish: metro por segundo
I think that 'per' is as much english as 'divided by'. People who know english won't be confused by it.
There's no question that it can only be "per". Using "div" suggests that a mathematical division is being done when it is not - it is no more
Andy Little wrote: possible to divide a metre by a second than it is to divide an apple by an orange. "Per", meaning "for each", is the term used in scientific terminology, and so that it the term that should be used, if any. What other languages use is somewhat of a red herring. If you want to incorporate localisation, great, use the equivalent of "per" in your local language, but for the English version, don't worry about what the non-English-speaking world uses. "Per" is scientific and "div" is mathematical, so stick with the former only. Paul
On Thu, Jun 08, 2006 at 08:31:37AM +0100, Andy Little wrote:
"Deane Yang" wrote Carlo Wood wrote:
English: meter per second Dutch: meter per seconde French: mtres par seconde German: meter pro sekunde Spanish: metro por segundo
I think that 'per' is as much english as 'divided by'. People who know english won't be confused by it.
I also vote for "per".
I never "voted" for per, I just said that div and per are both English and one shouldn't worry about one being confusing while the other is not. The few language examples that were given are just to back that up for this particular case. I agree with Paul Giaccone that's it's just a red herring, actually. Sorry for the confusion. I have to agree with Paul's remark about not actually doing a division too. And now I think about it, there is another reason to prefer 'per' over 'div': If you use 'div' then you insinuate that you are dividing, and therefore that you are multiplying the other terms. Thus, pascal (pressure, in N/m^2) is kg/(m s^2) would be kg_div_m_s2, insinuating: kg / m * s^2 However, that means (mathematically): (kg / m) * s^2 By using 'per', it is more plausible to give '_' a higher precedence than 'per'. kg_per_m_s2 can more easily be defined to mean kg/(m s^2). It seems that the correct way to pronounce it normally seems to be kilogram per meter per second per second, or kilogram per meter per second-squared. The 'per' is repeated, thus. So, should it be: kg_per_m_s2 or kg_per_m_per_s2 ? In the latter case, my argument against div doesn't hold anymore, of course.
in this case, as typedefs for declaring a quantity of a particular type , you end up with
velocity:: m_per_s velocity:: mi_per_h acceleration::m_per_s2; reciprocal_time::per_s; reciprocal_mass::per_kg; mass_flow::kg_per_s;
It might even be possible to abbreviate it and keep the sense:
velocity:: m_p_s velocity:: mi_p_h acceleration::m_p_s2; reciprocal_time::p_s; reciprocal_mass::p_kg; mass_flow::kg_p_s;
FWIW
I'd prefer the full 'per'. What is 'mi'? Shouldn't you use the full english word everywhere? That is less confusing. You also don't write 'rec_mass::per_kg'. The only exception to the rule of abbreviation should be for the (SI?) units and the prefixes: nm, mm, km, kg, Pa, N, cd, etc. I'm not even sure if we want to abbreviate non-SI units: feet, calories, barrels, acres, inches, buckets... By the way - if you abbreviate kilo to k, and mili to m. Then what is the full list? (from http://www.ex.ac.uk/cimt/dictunit/dictunit.htm) yotta [Y] 1 000 000 000 000 000 000 000 000 = 10^24 zetta [Z] 1 000 000 000 000 000 000 000 = 10^21 exa [E] 1 000 000 000 000 000 000 = 10^18 peta [P] 1 000 000 000 000 000 = 10^15 tera [T] 1 000 000 000 000 = 10^12 giga [G] 1 000 000 000 (a thousand millions = a billion) mega [M] 1 000 000 (a million) kilo [k] 1 000 (a thousand) hecto [h] 100 (a hundred) deca [da]10 (ten) 1 deci [d] 0.1 (a tenth) centi [c] 0.01 (a hundredth) milli [m] 0.001 (a thousandth) micro [µ] 0.000 001 (a millionth) nano [n] 0.000 000 001 (a thousand millionth) pico [p] 0.000 000 000 001 = 10^-12 femto [f] 0.000 000 000 000 001 = 10^-15 atto [a] 0.000 000 000 000 000 001 = 10^-18 zepto [z] 0.000 000 000 000 000 000 001 = 10^-21 yocto [y] 0.000 000 000 000 000 000 000 001 = 10^-24 I could agree with the more known ones: peta (P), tera (T), giga (G), mega (M), kilo (k), deci (d), centi (c), milli (m), nano (n), pico (p), femto (f)... but then again, that's just me (being familiar with those and not the others). I suppose you should support them all. I suppose that using 'u' as abbreviation for micro makes most sense (there isn't a 'mu' symbol in the C++ character set). -- Carlo Wood <carlo@alinoe.com>
Carlo Wood wrote:
On Thu, Jun 08, 2006 at 08:31:37AM +0100, Andy Little wrote:
"Deane Yang" wrote Carlo Wood wrote:
English: meter per second Dutch: meter per seconde French: mtres par seconde German: meter pro sekunde Spanish: metro por segundo
I think that 'per' is as much english as 'divided by'. People who know english won't be confused by it.
I also vote for "per".
I never "voted" for per, I just said that div and per are both English and one shouldn't worry about one being confusing while the other is not. The few language examples that were given are just to back that up for this particular case. I agree with Paul Giaccone that's it's just a red herring, actually. Sorry for the confusion.
I'd prefer the full 'per'. What is 'mi'? Shouldn't you use the full english word everywhere? That is less confusing. You also don't write 'rec_mass::per_kg'. The only exception to the rule of abbreviation should be for the (SI?) units and the prefixes: nm, mm, km, kg, Pa, N, cd, etc. I'm not even sure if we want to abbreviate non-SI units: feet, calories, barrels, acres, inches, buckets...
By the way - if you abbreviate kilo to k, and mili to m. Then what is the full list? (from http://www.ex.ac.uk/cimt/dictunit/dictunit.htm)
yotta [Y] 1 000 000 000 000 000 000 000 000 = 10^24 zetta [Z] 1 000 000 000 000 000 000 000 = 10^21 exa [E] 1 000 000 000 000 000 000 = 10^18 peta [P] 1 000 000 000 000 000 = 10^15 tera [T] 1 000 000 000 000 = 10^12 giga [G] 1 000 000 000 (a thousand millions = a billion) mega [M] 1 000 000 (a million) kilo [k] 1 000 (a thousand) hecto [h] 100 (a hundred) deca [da]10 (ten) 1 deci [d] 0.1 (a tenth) centi [c] 0.01 (a hundredth) milli [m] 0.001 (a thousandth) micro [µ] 0.000 001 (a millionth) nano [n] 0.000 000 001 (a thousand millionth) pico [p] 0.000 000 000 001 = 10^-12 femto [f] 0.000 000 000 000 001 = 10^-15 atto [a] 0.000 000 000 000 000 001 = 10^-18 zepto [z] 0.000 000 000 000 000 000 001 = 10^-21 yocto [y] 0.000 000 000 000 000 000 000 001 = 10^-24
I could agree with the more known ones: peta (P), tera (T), giga (G), mega (M), kilo (k), deci (d), centi (c), milli (m), nano (n), pico (p), femto (f)... but then again, that's just me (being familiar with those and not the others). I suppose you should support them all. I suppose that using 'u' as abbreviation for micro makes most sense (there isn't a 'mu' symbol in the C++ character set).
I think "mi" is meant to be "mile". The problem with imperial units is that, unlike SI units, they do not have standard symbols (actually abbreviations in the case of imperial units). So "mile" is often abbreviated to "m" (which can be confused with "metre", of course), as in "mph", and sometimes "mi", as in "London: 30 mi". Furthermore, the abbreviations for some imperial units can be pluralised, so "inches" is often abbreviated to "ins", something that is not allowed with SI units. So perhaps it might better to spell non-metric units out in full, if they are to be included, because they break a lot of the rules fixed for SI units. There are lots and lots of non-SI units... how many would it be useful to include? CGS units (ergs, dynes)? Nautical units (knots, fathoms)? Old units (leagues, cubits)? Units used outside the US and UK (arpents, taels)? Units that apply to only to particular commodities (carats, steres, jeroboams)? You'll find a very long list at http://en.wiktionary.org/wiki/Appendix:Weights_and_measures, and even that is not complete (no doubt there are longer lists elsewhere on the Internet). It would be fun to include all of these, but maybe not worth the effort if they were never used. Then again, they would extend the usability of the library. Yes, "u" is a conventional way of representing "mu" when the Greek letter is not available - you see "ug" quite often as the symbol for "microgram" on bottles of vitamins and medicines. I don't know whether this is an SI standard, but it is certainly commonly used. A few other thoughts... Centi-, deci-, deca- and hecto- are not officially part of SI nomenclature. Although "centimetre" is in very common everyday usage, and others such as "hectolitre" are sometimes seen, units such as "deciohm", "hectovolt" and "decapascal" have no official usage. So should the powers 10^n where n is not a multiple of 3 be allowed or not? Maybe it should be for metres but not for any of the other units, or maybe there could be a "strict" flag that turned these unofficial forms off or on. Does the second officially take any prefix? Can you talk about a "megasecond", or would you convert this to the more usual "11 days, 13 hours, 46 minutes and 40 seconds"? Indeed, does the library have a mechanism for doing this sort of breakdown of time? I suspect not, as time is not base 10. Is the litre officially an SI unit? I think I remember reading somewhere that either it is not, or it was not but has now been included. In any case, it's equivalent to 1/1000 m^3, but this often looks odd when referring to liquid, and petrol is sold in litres all over Europe, not cubic metres. The UK tends to use "gram" (like the US) these days rather than "gramme", which is a bit old-fashioned. But, again, you might want to support both spellings if you give a UK/US spellings option. It looks like there is a large number of things to consider in this library. I hope the ever-growing wish list doesn't end up pushing the release date of the library back for ever or causing it to end up being rejected just because there is a host of extra requirements that it does not yet fulfil. Paul
On Thu, Jun 08, 2006 at 02:49:07PM +0100, Paul Giaccone wrote:
Does the second officially take any prefix? Can you talk about a "megasecond", or would you convert this to the more usual "11 days, 13 hours, 46 minutes and 40 seconds"? Indeed, does the library have a mechanism for doing this sort of breakdown of time? I suspect not, as time is not base 10.
Is the litre officially an SI unit? I think I remember reading somewhere that either it is not, or it was not but has now been included. In any case, it's equivalent to 1/1000 m^3, but this often looks odd when referring to liquid, and petrol is sold in litres all over Europe, not cubic metres.
The UK tends to use "gram" (like the US) these days rather than "gramme", which is a bit old-fashioned. But, again, you might want to support both spellings if you give a UK/US spellings option.
Most of this is really just limited to input/output (serialization). I wouldn't object to a base library that supports the S.I. units, and calculates in those. The default output should be m^3 (or m3 or whatever) instead of litre. It would be nice to add conversion possibilities, like: std::cout << pqs::ios::litres << volume; outputting 'litre' instead of 'm3', but the number of possible formats are endless, and so are the preferences of different people. It seems logical to seperate the serialization of the variables from the library in a way that it becomes very very flexible. Sure, there should be some acceptable, and mostly scientific correct default, but you can't expect any user to be satisfied unless they will be able to implement their own serialization for their own specific case. (TeX, HTML, chinese, multi-line ASCII, full english, S.I. units, some other system(!), etc). -- Carlo Wood <carlo@alinoe.com>
Carlo Wood said: (by the date of Thu, 8 Jun 2006 16:06:47 +0200)
std::cout << pqs::ios::litres << volume;
outputting 'litre' instead of 'm3', but the number of possible formats are endless, and so are the preferences of different people.
Im accustomed to using decimetre^3, always abbreviated as dm^3, which equals exactly 1 litre (because it's 10x10x10 centimeters = 1x1x1 decimeter ) -- Janek Kozicki |
"Janek Kozicki" <janek_listy@wp.pl> wrote in message news:20060608181103.22f78f81@absurd...
Carlo Wood said: (by the date of Thu, 8 Jun 2006 16:06:47 +0200)
std::cout << pqs::ios::litres << volume;
outputting 'litre' instead of 'm3', but the number of possible formats are endless, and so are the preferences of different people.
Im accustomed to using decimetre^3, always abbreviated as dm^3, which equals exactly 1 litre (because it's 10x10x10 centimeters = 1x1x1 decimeter )
Although liter is equivalent to 1 dm^3, technically its not an SI unit. Its not in the review version of PQS, but it is possible to add a liter unit to volume header and get output as 1 L or whatever is preferred... I just did this in my local version of PQS. The sequence of steps is 1) In <boost/pqs/meta/components/of_volume.hpp> Add a typedef for the liter in the incoherent_unit struct (starts at line 47). typedef meta::unit< boost::pqs::meta::rational<-3>, meta::rational<1>::type, boost::mpl::int_<1> > liter; 2) In <boost/pqs/t1_quantity/types/volume.hpp> Add the typedef for liter to the other member typedefs: typedef t1_quantity< type, typename incoherent_unit::liter, Value_type > liter; 3) In <boost/pqs/t1_quantity/types/out/volume.hpp> add the stream output overload for the liter unit: inline std::ostream& operator <<( std::ostream & os, t1_quantity_units_out< meta::components::of_volume::type, meta::components::of_volume::incoherent_unit::liter > ) { os << "L"; return os; } Check it works: #include <boost/pqs/t1_quantity/types/out/volume.hpp> using boost::pqs::volume; int main() { volume::liter v(1); std::cout << v <<'\n'; volume::m3 v1 = v; std::cout << v1 <<'\n'; } Outputs: 1 L 0.001 m3 Because liter isnt an SI unit you would need to add cL and mL in the same way (I guess that would be the next question!) regards Andy Little
"Paul Giaccone" wrote
It looks like there is a large number of things to consider in this library. I hope the ever-growing wish list doesn't end up pushing the release date of the library back for ever or causing it to end up being rejected just because there is a host of extra requirements that it does not yet fulfil.
AFAICS the pqs review is suffering from a lack of official reviews and that will end in rejection more likely than aceptance. Of course I feel that PQS should be in boost else I wouldnt have put the library forward, however currently I think there are the same or more no votes than yes votes, IOW if you feel strongly then I would urge you to write a review, whatever your vote. Review ends tomorrow BTW. regards Andy Littlel
Andy Little wrote:
It might even be possible to abbreviate it and keep the sense:
velocity:: m_p_s velocity:: mi_p_h acceleration::m_p_s2; reciprocal_time::p_s; reciprocal_mass::p_kg; mass_flow::kg_p_s;
Please, less abbreviations. You, as the inventor of the abbreviations, might find them easy to keep track of, but I, with an aging and rapidly deteriorating memory, find them too cryptic. The elimination of cryptic abbreviated names is for me one of the major advances in programming.
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Deane Yang | Sent: 08 June 2006 17:01 | To: boost@lists.boost.org | Subject: Re: [boost] [review] pqs | | Andy Little wrote: | | > It might even be possible to abbreviate it and keep the sense: | > | > velocity:: m_p_s | > velocity:: mi_p_h | > acceleration::m_p_s2; | > reciprocal_time::p_s; | > reciprocal_mass::p_kg; | > mass_flow::kg_p_s; | > | | Please, less abbreviations. You, as the inventor of the | abbreviations, | might find them easy to keep track of, but I, with an aging | and rapidly | deteriorating memory, find them too cryptic. The elimination | of cryptic | abbreviated names is for me one of the major advances in programming. Agree strongly. Am thinking of founding a scoiety for the Abolition of TLAs. You can guess its acronym ;-)) Type once, read many, so DON'T abbreviate. Yours senility... Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
"David A. Greene" <greened@obbligato.org> writes:
It is also, IMHO, one of the best practical examples of template metaprogramming.
I just want to clear something up about this. It's not directed at PQS in particular, but at the whole domain of dimensional analysis as an example of TMP. Dimensional analysis is really a very poor example of what TMP can do: interesting TMP involves some generation of code that actually "does something," as in the state machine example in C++TMP or Blitz++ expression templates or Boost.Lambda. Dimensional analysis basically only adds error messages where they wouldn't otherwise have been. I recently had the same conversation with Scott Meyers, so you're not in bad company ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"David A. Greene" <greened@obbligato.org> writes:
It is also, IMHO, one of the best practical examples of template metaprogramming.
I just want to clear something up about this. It's not directed at PQS in particular, but at the whole domain of dimensional analysis as an example of TMP.
Dimensional analysis is really a very poor example of what TMP can do: interesting TMP involves some generation of code that actually "does something," as in the state machine example in C++TMP or Blitz++ expression templates or Boost.Lambda. Dimensional analysis basically only adds error messages where they wouldn't otherwise have been.
Not to nitpick, but I didn't say "interesting," I said "practical example." Catching these kinds of errors at compile-time is immensely practical. Not that lambda, etc. are not, but dimensional analysis is something that most programmers can grasp immediately, amking it a very good example of the usefulness of TMP. Essentially, TMP is being used to extend the type system. When I talk to, say, Java users about TMP, this is something they can grasp. -Dave
participants (17)
-
Andy Little -
Benoit -
Beth Jacobson -
Carlo Wood -
David A. Greene -
David Abrahams -
David Greene
-
Deane Yang -
Gerhard Wesp -
Janek Kozicki -
Leland Brown -
Martin Adrian -
Paul A Bristow -
Paul Giaccone -
Pavel Vozenilek -
Phil Richards -
Thomas Witt