-----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Sebastian Redl | Sent: 03 June 2006 22:33 | To: boost@lists.boost.org | Subject: Re: [boost] [Review][PQS] Physical Quantities | System review (May 31through June 9) | | Pavel Vozenilek wrote: | | >1. The name "pqs" should be changed to | > something a little bit more descriptive. | > | > "unit" feels quite handy. | > | > | "Unit" in programming is closely associated with the | technique of unit testing, Most end users, mainly scientists, using it will not have heard of UNIT testing - just testing - and they may not do much of that ;-( | and a library of that name would probably be confused with | Boost.Test. (See existing libraries like CppUnit.) Boost.Units is NOT going to be confused with Boost.Test, IMO. (And Andy cunningly manages to handle non-SI units, vital for the once Imperial [ now renamed Colonial? ;-) ] units still beloved by the US, so putting SI in the title won't do at all). | I like PQS. I absolutely HATE it! Does conjure up anything except acute acronymitis ;-) (I also hate the wholey non-descriptive t1_quantity - surely we can do better than that?) 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, When talking about physical quantities, I'd like to ask a related subject - math constants. They would be really handy inside boost (not as a separate library). Err.. what is the status of including your math constants library ? PS: sorry about abrupt subject change. -- Janek Kozicki |

Andy Little said: (by the date of Mon, 5 Jun 2006 16:12:30 +0100)

"Janek Kozicki" <janek_listy@wp.pl> wrote in message

...

Hi Paul,

When talking about physical quantities, I'd like to ask a related subject - math constants. They would be really handy inside boost (not as a separate library).

Err.. what is the status of including your math constants library ?

It might be worth asking Paul (Bristow)about that. ( I wasnt one of the math constants authors)

The math constants included with pqs are in my preferred format and seem to work OK. It might be worth removing the math and physics ( for physics constants) sub namespaces though, as they dont add much IMO.

oops, I didn't notice that you have math constants in pqs. Well then - when pqs gets to boost I don't need to care about others math constants libraries. There should be just one in boost, right? there is a noteworthy post by Paul, about maths constants: http://tinyurl.com/m8zhd especially point 9 in the list ;) -- Janek Kozicki |

--- Paul A Bristow wrote:

Disheartened by the vociferous criticism of a (the) very few reviewers, (over use cases that I judged not important enough to reject the idea) I have not made any changes to the method of presentation or the list.

No criticisms from me.

However, I am coming to the view that the politically incorrect macros may be the best way to insert the decimal digit strings into the right places in users code.

Practicality is my most important consideration, and your library is definitely more practical than MPL.Math at the moment. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

"Pavel Vozenilek" wrote

"fred bertsch" wrote:

...

The review of Andy Little's Physical Quantities System begins today,

I do abstain in this voting.

The documentation could be improved a lot. I didn't spotted problems in the code, the tests compile (with tiny fix [13]) and the usability of the library looks within reach of normal developer.

/Pavel

_______________________________________________ 1. The name "pqs" should be changed to something a little bit more descriptive.

"unit" feels quite handy.

Thanks for the suggestion. I am OK with changing the namespace to unit if it makes more sense to do so. ______________________________________________

2. intro.html: I find some terms as "t1_quantity" rather annoying. What they mean? How do these names help novice to understand the library better?

I would recommend to avoid the t1, t2, ... nomenclature. I know about few projects named tX, it is better to avoid such associations.

I have had similar feedback regarding the name t1_quantity. The problem is that there is potentially a family of 3 different types representing quantities and it is not easy to express their individual characteristics together with some expresion of their similarities. The latest I could come up with has been chico_quantity, harpo_quantity and groucho_quantity. At least it gets away from the numbers. In source code, the expected useage is to use the typedefs ( pqs::length::m etc), in the same way that std::string is a typedef for std::basic_string<...>. t1_quantity will come up in error messages and be used for generic functions though.

The funny "physical_quantity" uses underscore intentionally? Shoudn't italics or different font be used?

The idea is that its meant to be a keyword. Maybe that should be 'physical quantity' or 'physical-quantity' though. I once used bold italic for all hyperlinked keywords in a document, but the reviewer reported that they gave him a headache. I will have to experiment with fonts to see whats best.

What may be implemented in the future should be moved out of introduction. A novice will have enough of troubles to grasp what's available now.

Originally, I wished to avoid the library becoming a framework ( where by framework I mean that it requires its own supporting classes), however what I have discovered in the course of writing the library is that you cant implement stronger type checking and expect the library to operate with traditional libraries(such as matrix libraries, complex and so on). The only way to do that is to remove the type checking. Therefore I think its important to stress in the introduction that what is here would only be a small part of a much larger framework.

Marketing ala "Increases programmer satisfaction and enhances productivity" should be left out. It is up to the user to decide usability of the library.

OK. _______________________________________________

3. definitions.html: ERD abbrev should be spelled fully. Smaller and more focused parent - child diagrams could be added for every term, instead of pointing to one huge and hard to grasp quickly graph.

The detailed description of terms should start from the basics and the most simple and continue toward more complex terms - the lexicographic ordering is not that helpful. The ordered list on top is OK.

Every single term should have example or link to example. It is too information dense as it is now and it doesn't give enough of clues to novices.

There is definitely a problem with the emphasis that is placed on the whole definition of terms section. The idea behind putting it first is to let the reader know it is there. The intent was that the reader would notice it, but skip it and only refer to it when necessary. This is one downside of using Quickbook. By default It tends to impose a sequential style ( with the prev/ next arrows), whereas in my hyperlinked documents I prefer to use a 'star' and or hierarchical system with the index as the hub and directories. The entity relationship diagram could be nested to more detailed areas as you suggest and might serve as the basis for a much more graphics based approach generally.

I was not able to understand the last paragraph in base_dimension section.

The idea of a base_dimension is that it isnt reduceable. For example length is a base dimension. However it is possible to have a physical quantity of length to power 1/2. A philosopher can use this to pick holes in the idea that length is irreducible. This is a note to say that the choice of base-dimensions is rather 'loose' and not to be taken too seriously. They are accepted practical conventions only.

It shlould be always spelled what every term means in C++: class, typedef, constant, variable, concept?

OK. I will admit that I have got continually confused in the Specification section as to what is a concept, a classs, a typedef etc. Basically I find writing code a lot easier than writing a specification. The specification section needs to be redone to sort all these entities out.

In "dimension": what is "show access to dimension typedef in t1_quantity"???

Ooops. That is an authors note which got left in by mistake. I confess I dont know quite what it means myself, but it shouldnt be there.

I am not sure whether "incoherent_unit" is the best term - perhaps traditional or historical or specialised.

The incoherent_units are called such as they dont fit neatly in the S.I system, needing odd multipliers and so on. I should probably make a more in depth study of the S.I terminology and rework the definitions trying to stick as close as possible to the ones in the S.I.

C.G.S. is not linked.

There doesnt seem to be an authority that maintains it. Its kind of a historical curiosity AFAIK. ______________________________________________

4. There should be "How to..." for most importants use of the library. Acknowledgements should be the last page. Not many people will have stamina to read through all the stuff to find out what is the library good for.

Ok. I was taught that Acknowledgements should appear after the intro. However I later found that every institution puts it somewhere different. Again I believe that moving the docs toward a 'star' rather than sequential layout would solve this.

_______________________________________________ 5. A table listing all namespaces and all relevant typedefs inside, all hyperlinked, is missing. The information may be present but not in single location and compact form.

Instead of lot of free text I would much more prefere tables and examples.

OK. This is basically due to a heavy learning curve in learning how to write technical documentation. I will certainly study other docs to see how it should be done.

_______________________________________________ 6. rationale.html: instead of headings as "clarity" a technical description should be used, e.g. "replacing untyped calculation with typed" or so.

Dtto the "More enjoyable programming" and so on.

The example in "More enjoyable programming" doesn't say explicitly what useful happens inside. Even after several readings I am not able to understand what one should expect to learn here.

"Code integration" section is empty of information. And what gets integrated where?

I guess that this is not very meaningful. What I am getting at is that the library can potentially provide a common format for sharing physical quantity data between applications. In practise that aspect of the library hasnt been achieved so far, except for common output format.

_______________________________________________ 7. Not only examples that show how somethink works but also examples that show what fails and what kind of mistakes the library prevents should be included. Such examples could easily get the most useful resource for the learning process.

Yes. I need to add some examples of applications where the library wont help as much as one might think, as well as applications where it works well.

_______________________________________________ 8. All examples in libs/pqs/examples should be linked from the main documentation with explicit note what one should notice in each of them.

Right. That probably means providing a better targetted set of examples too.

_______________________________________________ 9. library_interface.html:

The text like "...the complexities are hidden behind a simple interface and its not necessary to know the full details of the type to make good use of it" >> /dev/null

Well. Unfortunately I have already presented the reader with the complexities in the definition of terms section. I probably need to move that to the end so that the reader can get to the Getting started section.

Path names as #include <boost/pqs/t1_quantity/types/length.hpp>

- I am against showing history related details (t1, t2, ..) to the user. One wants to used the library w/o hassle, not to deal with "t1".

I dont follow what you are saying here. Do you mean that I should use more meaningful variable names?

"Stream output" section - the exmple should mention what is actual output as a comment next to the << operation. All examples should be consistent in style.

OK. It is there but not part of the code block. I will experiment with the layout to see how to do it consistently.

I am not sure whether stream I/O formatting really belongs to the library - there could be large issues with I18N. There should be separate page in the documentation detailing current use and what one could do to use own formatting.

In practise the great advantage of the I/O formatting is that it is very helpful for debugging and examples. Maybe though it should be constructed similarly to standard locales.

Examples: I would like to see longer names for variables than "t", "t1", "m1", "v1". Especially the "t1" irks me in he context.

Ok. I should spend time on more meaningful names.

The terms as "dimensionful" in sectin names should be hyperlinked. Dimension-full feels more readable.

Yes. The hyper-linking needs to be more consistent throughout the docs.

"Addition and subtraction" section: the heavy hyperlinking over and over makes the text practically unreadable. I really recommend to get rid as much of free text as possible and replace it with more structured content (including examples).

This is difficult because the semantics are very complicated. I have tried to start with just demonstrating what can be done in the Getting Started section, followed by more detail but still informal in the 'Semantics of operations section, followed by a rigid spec in the specification section. Maybe I should get rid of one section, but the informal semantics section is much lighter reading than the spec.

"Multiplication, division" - small examples should follow every sentence. It is hard to identify them in the large blob bellow.

"Calculations - performance" - last paragraph is about what?

Its attempting to reassure the reader that the code produced is efficient, as its not clear from the previous sections This should probably be a whole separate section comparing performance with builtin types to see how the two compare in speed code size etc.

_______________________________________________ 10. t1_quantity.html:

The macros - are the really needed when Boost has existing typedefs?

Unfortunately the BOOST_PQS_INT32 macro is needed because it is used as a non-type template parameter. typedefs wont be accepted. BOOST_PQS_REAL_TYPE might be better as typedef.

"Values" section - I am unable to understand what it describes and what it could be used for.

OK. There is some duplication with the MACROS section, as well as some unnecessary customistation which should probably be removed.

I completely gave up reading the rest of page - I do not see structure or some anchor point.

Fair enough. The whole technical section of the docs is a mess and needs rewriting.

_______________________________________________ 11. rest of documentation:

length.html: point (prn) - I guess this means printing (or better prepress) but does everyone know?

OK. Ideally that should probably be a hyper link to a short note about the unit. There are a large number of units. Currently I am using a database. I was vaguely hoping to convert this into an XML database. Adding notes per units could be opart of that work.

The "acre" here is length or breadth?

hmm. That should be an area. I'm not sure how that got there. There is an area::acre too. Looks like a problem in my header generator.

voltage.html: abvolt and such curiosities should be linked to external definition, if only to verify that the implementation is correct.

Perhaps a link to http://www.unc.edu/~rowlett/units/ would be the best.

Yes that might work very nicely.

physical_constants.html: year or so ago library by Paul Bristow providing many constants was on review (and rejected for the time). If it is still worked on it would be good to coordinate the content.

The same idea was peresented by Alf P. Steinbach. message 5 in this thread on comp.std.c++: http://tinyurl.com/rspvv

extending.html: this should have form of tutorial, with steps 1., 2., 3. ... and description how to verify the result.

reference.html: why is Google redirect there? The CUJ link should be changed to current DDJ.

OK.

_______________________________________________ 12. Normal headers and "out" headers. Perhaps these should be merged together. The code in pqs library uses so much of other Boost functionality that additional <iostream> and <sstream> won't make difference on compilation time (it takes seconds to tens of seconds to compile any example on my machine with Intel 9, the streams alone take less than second).

IMHO it is worth to make the lib simpler to use.

OK. That may be a good idea.

_______________________________________________ 13. t1_quantity/operations/compare.hpp:

The #include <cmath>

should be replaced with

#include <boost/compatibility/cpp_c_headers/cmath>

which works for Intel C++ plugged in VC6 IDE with old Dinkumware.

OK.

The header <boost/compatibility/cpp_c_headers/cmath> has a bug (abs() is missing) but it has been reported.

OK. I'll try that out. _______________________________________________

14. typeof_register.hpp: the warning against Typeof changes after admitting to Boost should be updated/removed.

OK. Hopefully Typeof will be out soon :-)

_______________________________________________ 15. quantity_traits.hpp: the constants max_default_named_quantity_tag would look better as MaxDefaultNamedQuantityTag. It is rather conventional style.

OK. I may remove this anyway, as its rather obscure.

--------- The names in template<typename T, typename S> could be more expressive.

Again I think that I may remove converter customisation from the interface. I dont see a great advantage in having it there.

_______________________________________________ 16. Indentation style. The classes would be better moved to the very left side (i.e. ignoring namespaces). Currently way too many lines get splitted in half and the result is harder to parse (by humans).

4 or 8 characters could be gained for lot of the code.

OK. I will try it, though I prefer indenting consistently as a rule

_______________________________________________ 17. config.hpp: the BOOST_PQS_SUPPRESS_VC8_ADL_BUG should be likely limited to VC8.

OK.

-------------- BOOST_PQS_DEFINE_PHYSICAL_CONSTANTS_IN_HEADERS may have some comment nearby what to do when compiler doesn't support the feature.

OK.

_______________________________________________ 18. concept_checking.hpp: if possible style of #include should be the same all over:

#include "boost/type_traits/is_arithmetic.hpp" #include <boost/concept_check.hpp>

OK.

------ Quite a large block of commented out code exists here. It should be used or removed.

This is a function of moving from concept checking classes to enable if and other forms. I experimented with various compiletime error diagnostic schemes and havent really decided which is best.

------

Perhaps BOOST_STATIC_ASSERT could be used instead of rolling out own Assert (just a minor point).

I found that useful for derivation: struct myClass : Assert<Pred>{/*...*/) gives a nice error message including a local pqs concept-checking header which helps to identify it. Again it is a question of deciding on one style I guess.

The Pair<> could be possibly replaced by std::pair.

Thats true, or mpl::pair.

_______________________________________________ 19. utility/timer.hpp: this looks as if it should be in test/ or examples/ folder.

Yes. There is some overlap with other boost timers too!

_______________________________________________ 20. The whole pqs/two_d: is this documented somewhere or is it start of future work? Dtto three_d.

Not documented yet. These are all intended to be supporting framework for the library. Its potentially a huge library.

_______________________________________________ 21. t1_quantity/t1_quantity.hpp:

public function get_united_value() returns something from detail sub-namespace.

That could probably be shut.

_______________________________________________ 22. t1_quantity/types/capacitance.hpp (and others):

Types as GF (giga Farad) or even much bigger are defined. I am not sure whether in current universe such capacitance could exist. Perhaps those physically impossible types could be pruned out to avoid mistakes caused by typos (for example mF and kF are easy to mis-type).

When someone wants GF then he may add such thing manually.

Or perhaps there could be a macro like USE_FULL_EXTENT_FOR_UNITS that enables such types.

Yes . especially bad for Temperature. These headers are generated. I should add some limits per header.

-------- And when I am at it: when one uses nF and mF mistake is easy to happen and hard to spot.

I would love to have typedefs with names like nano_farad and micro_farad available as well. The cost of typing is smaller than searching for a bug caused by wrong unit.

Thats worth thinking about, but I would be concerned about the duplication. I prefer one interface typedef. I'm not sure about that.

_______________________________________________ 23. The t1_quantity/types/xxx.hpp should contain exact information where in the documentation look for recipe how to create new types.

(And the docs should refer this file.)

Yes. That needs a lot more work.

_______________________________________________ 24. t1_quantity/types/time.hpp:

I would prefer to spell a type as "week" instead of "wk".

The names are based on those in the SI. That seems to be a good reference for the names of units, and as the library matures I am more and nmore convinced that it should closely follow the SI specs if possible.

_______________________________________________ 25. Naming: people may not like long names like boost:pqs:xyz.

Perhaps there could be a macro that, given a namespace (i.e. global) and common name prefix, will create all typedefs where the user likes them. Something as

BOOST_UNITS_DECLARE_ALL_IN(::, unit_)

and then "unit_m" would be meters.

Maybe. but user can use namespace alias , typedef or using for preferred set of units. Unless the current mechanism is unacceptable I am in favour of not providing alternatives.

_______________________________________________ 26. The library provides dimensionless units (if I understanding it correctly).

Its not intended too. Its intended that units are only applied to dimension-ful quantities, (except for angles)

For many applications these would be the most useful ones. There should be page dedicated only to this functionality, not bothering a read with Farads and inches.

As it stands this is part of the implementation in <boost/pqs/detail/united_value/> . It may be worth making it a public part of the library, though I hadnt thought about that before.

There should be examples like number_of_apples = number_of_oranges; // error number_of_fruit = number_of_apples; // OK that give enough of clue without need to read the whole documentation.

As it stands the library is concerned with the SI definition of physical quantities. What you describe is a different library AFAICS. (Often requested by boosters). PQS isnt that one though.

_______________________________________________ 27. The documentation should say (perhaps I missed it) whether the different unites could be used for overloading of functions, with example(s).

OK.

_______________________________________________ 28. As I read the code, Boost.Serialisation is not explicitly supported and won't work by out of box. I guess it should be reatively easy to add.

Yes. I did a demo with boost Serialisation. I should add it to examples. Thanks again for your comprehensive review. regards Andy Little

"Pavel Vozenilek" wrote

_______________________________________________

...

...

1. The name "pqs" should be changed to something a little bit more descriptive.

"unit" feels quite handy.

Thanks for the suggestion. I am OK with changing the namespace to unit if it makes more sense to do so.

Whether unit or something else - psq would be maintenance headache (TLAs should not be used, there are enough of domain specific ones).

I could change the name from pqs to si_units in reference to Walter Browns library. http://physics.nist.gov/Pubs/guidelines/TN1297/tn1297s.pdf That would also reinforce the SI foundations of the library.

______________________________________________

...

...

2. intro.html: I find some terms as "t1_quantity" rather annoying. What they mean? How do these names help novice to understand the library better?

The latest I could come up with has been chico_quantity, harpo_quantity and groucho_quantity.

That's too US centric. If a property of quark is referred as red/blue/green then C++ library may as well.

Its a tricky problem. colours denote electro-magnetic radiation within certain frequency ranges of the spectrum.

...

This is one downside of using Quickbook. By default It tends to impose a sequential style ( with the prev/ next arrows), whereas in my hyperlinked documents I prefer to use a 'star' and or hierarchical system with the index as the hub and directories.

Quickbook is not mandatory. The best documentation currently in Boost is not limited by it, for better.

Quickbook is convenient and as the docs are large I am tempted to stick with it as there is a lot of docs to do. It is certainly an improvement in productivity over HTML anyway. There are probably ways to customise Quickbook/Docbook that I dont know about too, but the downside usually is that flexibility goes.

...

...

C.G.S. is not linked.

There doesnt seem to be an authority that maintains it. Its kind of a historical curiosity AFAIK.

Searching for this I found quite large collection of units: http://www.sizes.com/units/index.htm (http://www.sizes.com/units/sys_cgs_em.htm few CGS specific)

I can add this as a link for C.G.S system but my point is that its informal rather than official. AFAIK C.G.S has been swallowed up by the SI system.

...

...

Path names as #include <boost/pqs/t1_quantity/types/length.hpp>

- I am against showing history related details (t1, t2, ..) to the user. One wants to used the library w/o hassle, not to deal with "t1".

I dont follow what you are saying here. Do you mean that I should use more meaningful variable names?

I mean that #include <boost/pqs/types/length.hpp> should really cover current and future length metrics.

The "t1"s would be hard to maintain in legacy code

You mean that : #include <boost/pqs/types/length.hpp> should bring in the (socalled) t1_quantity, t2_quantity for length?. Its worth thinking about, though I do have certain doubts about putting everything in one header. It would make life simpler though. The current hierarchy is noticeably too deep.

...

...

The "acre" here is length or breadth?

hmm. That should be an area. I'm not sure how that got there. There is an area::acre too. Looks like a problem in my header generator.

I though so but found (in Wikipedia) that two historical length units of this name exist.

The Wiki reference I turned up: http://en.wikipedia.org/wiki/Acre suggests that this refers to components of an area.I am sure its an error, so I will have to look into how its turned up there. As you said previously there should of course be tests to check the validity of the named_quantities and their typedefs and constants too. Tests ned work like everything else.

_______________________________________________

...

...

14. typeof_register.hpp: the warning against Typeof changes after admitting to Boost should be updated/removed.

OK. Hopefully Typeof will be out soon :-)

I believe it will available in 1.34, at least it is in current CVS.

...

...

And when I am at it: when one uses nF and mF mistake is easy to happen and hard to spot.

I would love to have typedefs with names like nano_farad and micro_farad available as well. The cost of typing is smaller than searching for a bug caused by wrong unit.

Thats worth thinking about, but I would be concerned about the duplication. I prefer one interface typedef. I'm not sure about that.

It would be even more usefulf for historical, ahem, incoherent units. These could be used when a statement from old manuscript gets encoded. Here the wordiness would be especially handy.

A change of name from 'incoherent unit' to 'historical unit' is an attractive suggestion. I could change the term 'coherent unit' to 'SI unit' then. That might clarify things.

Another target group could be students/amateurs/those who forgot most of details long ago.

_______________________________________________

...

...

25. Naming: people may not like long names like boost:pqs:xyz.

Perhaps there could be a macro that, given a namespace (i.e. global) and common name prefix, will create all typedefs where the user likes them. Something as

BOOST_UNITS_DECLARE_ALL_IN(::, unit_)

and then "unit_m" would be meters.

Maybe. but user can use namespace alias , typedef or using for preferred set of units. Unless the current mechanism is unacceptable I am in favour of not providing alternatives.

The macro could be generated. Hand-typing the typedefs would not be the best past-time. There is also chance that someone may want to replace existing a legacy unit typedefs with the new library.

I could remove all the named_quantities part of the library and leave it to the user to deal with which sounds like what you are suggesting. That would certainly save me a lot of work. However from my own point of view ( as a user) I am quite lazy and I like all this work to be done for me. I feel that the current interface works reasonably well. A point that is remarkable about the current library is that basically its a large database of value_types rather than something to compose ones own types from. In fact the format of the naming convention for the named_quantity typedef isnt well documented, but the ambition was that the interface (ie length::m) communicates better than the class template t1_quantity<length,zero_unit,double> does. Apologies that I find it difficult to communicate what I am trying to say here. I feel that the interface ( which you want to be able to customise) is the most important part of the library in many ways. That is its most useful feature and is what saves the user time and effort, assuming they understand the 'feel' of it of course. The interface hides some rather messy details of the t1_quantity, ( coherent/incoherent units etc etc) . Remove the interface and the user is exposed to all that which is not good AFAICS. They then need to recreate their own interface. (Maybe I'm too attached to the current interface!)

_______________________________________________

...

...

26. The library provides dimensionless units (if I understanding it correctly).

Its not intended too. Its intended that units are only applied to dimension-ful quantities, (except for angles)

...

For many applications these would be the most useful ones. There should be page dedicated only to this functionality, not bothering a read with Farads and inches.

As it stands this is part of the implementation in <boost/pqs/detail/united_value/> . It may be worth making it a public part of the library, though I hadnt thought about that before.

I am quite curious about it. I once wrote a mini-library that provided ability to define types representing dimensionless quantities and transformation between them. It was possible specify which assignements are valid and conversion was automatic. It was very simplistic and the code is lost somewhere, though.

My conceptual problem with that is that it waters down the strong type checking. Taking your following example. These units only make sense as lengths. They cant be applied to forces or velocities. That is why its an implementation detail currently. Its really just an extended floating point type.

Example of use could be GUI units: pixels of screen, pixels on printer, inches for physical representation.

Use of physical quantities to represent screen coordinates I am quite keen on (whether modelled using PQS library or just by a set_units("millimeters") function. This is one area that pqs cant fulfill on its own and finds it difficult to mix different types of units, because some of these units are outside the realm of physical quantities. A screen pixel is device ( or device mode) dependent, whereas a millimeter is absolute. I cant remember the details but some specs (maybe SVG) use a weird hybrid where a printer point is 1.5 screen units on a certain screen resolution or some such monstrosity. pqs can only deal with the absolute type of units. Thanks again for your review and feedback on the library. regards Andy Little

"Pavel Vozenilek" wrote

Andy Little wrote

...

Pavel Vozenilek wrote

...

The "t1"s would be hard to maintain in legacy code

You mean that :

#include <boost/pqs/types/length.hpp>

should bring in the (socalled) t1_quantity, t2_quantity for length?.

Its worth thinking about, though I do have certain doubts about putting everything in one header. It would make life simpler though. The current hierarchy is noticeably too deep.

Yes. The "t1" is arbitrary symbol that doesn't make much of sense. When someone wants to use the units the include path should be intuitive

#include <boost/si_units/capacitance.hpp>

Thinking about it, that makes much sense and would greatly simplify life for users. Thanks for all the info. regards Andy Little

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Janek Kozicki | Sent: 06 June 2006 21:09 | To: boost@lists.boost.org | Subject: Re: [boost] [Review][PQS] Physical | QuantitiesSystemreview(May31through June 9) | | #include <boost/units/length.hpp> | | I don't care whether it's decided to left out "si_" from the | name due to | support of non-si units. Just pick name "units" or "si_units". I DO care - a lot! Names are REALLY important IMO. The library IS about units - not just quantities because without units, the quantity is meaningless. I think it would be VERY BAD mistake to fix the idea of SI only in the name, when ALL units (including 'zero' units) can be handled. "si_unit::length::in" looks plain daft. Much as SI units are preferable, sadly, other 'traditional' units are never going to go away. Lets keep the package as general as possible. What is important is that using them doesn't result in any more crashes on Mars, or elsewhere ;-) And anyway si_units is longer and more annoying to type, and it raises the doubts should it be SI_units or si_units? The code also handles units of things that are not really physical, so I think the PQ bit is also misleading, much as it distresses Andy to lose the name of his 'baby', so many years in gestation. So please, lets just stick to 'units' and call the package Boost.Units. KISS! 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 Greene" wrote

I agree, but unfortunately it is not general enough. See my review concerning the lack of non-power-of-10 prefixes. I think this library _should_ be a general units framework but it's not there yet. Until it gets there or there is a plan to get there, it should not be called "units."

This is theoretically fine. In practise I have a very long list of things to do just within the SI framework. Something has to be low priority and because this is well outside the current scope of the library, non-decimal prefixes is probably going to be low priority unfortunately. regards Andy Little

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote

...

...

14. typeof_register.hpp: the warning against Typeof changes after admitting to Boost should be updated/removed.

OK. Hopefully Typeof will be out soon :-)

I believe it will available in 1.34

This is definitely the plan. Regards, Arkadiy

"John Maddock" wrote: _______________________________________________

...

13. t1_quantity/operations/compare.hpp:

The #include <cmath>

should be replaced with

#include <boost/compatibility/cpp_c_headers/cmath>

which works for Intel C++ plugged in VC6 IDE with old Dinkumware.

The header <boost/compatibility/cpp_c_headers/cmath> has a bug (abs() is missing) but it has been reported.

Um no, those compatibilty headers *only work for broken compilers* for std conforming lib's that really do define the C names in namespace std they do not contain legal code. The idea is that if you are one of the few people still needing these headers then you'll simply add them to your include path.

The problem boils down to: #include <cmath> int main() { using namespace std; // error, no std namespace exists } on any compiler using the old Dinkumware. The TU would not include anything else from std namespace, as it happened with one of pqs tests. --------------- The fix within pqs would be: #include <cmath> #ifdef old-Dinkumware namespace std { using ::abs; // possibly others, or empty, just make std:: } #endif ... /Pavel

"David Abrahams" wrote:

...

"fred bertsch" wrote:

...

The review of Andy Little's Physical Quantities System begins today,

I do abstain in this voting.

Why? It seems like you certainly did enough analysis to make an informed vote.

I was not able to finish reading through the documentation. This doesn't make me confident enough to give judgements (apart that the documentation should really get more time). /Pavel

Hi Paul, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1FneN9-00014T-OY@he303war.uk.vianw.net...

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of fred bertsch | Sent: 31 May 2006 18:07 | To: boost@lists.boost.org | Subject: [boost] [Review][PQS] Physical Quantities System | review (May 31through June 9) | | The review of Andy Little's Physical Quantities System | | - What is your evaluation of the design?

Examples suggest that it should meet many needs of many users.

It may be worth noting that the potential users are scientific, engineering and education, which may be slightly different from regular boosters, but is still a wide user base

I like that it handles rational power units that some users really do need.

FWIW the inclusion of rational powers of dimension did initially increase compile time, so I had to spend considerable time customising this to get compile times down again.

| - What is your evaluation of the implementation?

Not very qualified to judge.

Seems complicated, but I fear this is necessary, and badly needs typeof to complete it,

Yes. Boost.Typeof becoming available in the next Boost release will really help to simplify use for 'auto' variables for intermediate results of complicated calculations and also faciliate composition of ones own quantity types, which can be a bit cumbersome at the moment without it. I need examples of that though too.... when Typeof comes out.

but it is best effort so far, and worth getting more people to try it 'in anger'.

Thanks. I have had some feedback that it seems to work well in refactoring at least small projects. Philosophically the library is an experiment in strong type checking. Its not painless. It does remain to be seen whether that scales or not though. Ultimately I need to emphasise that the library presented will need supporting classes. matrices, vectors, complex quaternion, entities representing (say) a force vector at a position etc , etc. for scaleability. Or ways to exit the type checking of course.

As noted before, I would very strongly prefer this called Boost.Units rather than PQS, (I am not convinced that it is limited to 'physical' quantities).

(Note plural UnitS to avoid any confusion with singular Unit Test, now Boost.Test).

I know that you previously didnt like the suggestion si_units, because some units arent SI , however my position is that we are being encouraged to move away from non-si units so calling the library si_units or SI_units does make sense to me. One might question the logic of: si_unit::length::in for inches though, implying that inches is an SI unit which it isnt. I could call the library PQSunits or some such ?

AND I think a more descriptive name(s) for "t1_quantity" etc is needed.

I know its bad!. I have been trying to come up with other names without much success so far though.

| - What is your evaluation of the documentation?

Useable, but badly needs some editorial work on spelling, punctuation etc.

OK. Unfortunately I dont find doocumentation easy or fun, but I will have to keep at it. I think it is getting better slowly.

I would put a QuickStart item at the very top with a typical example, and links to your examples, the link name showing its 'feature'.

Yes. There needs to be a reorgansiation of the layout.

ERD should be spelt out in full.

OK.

Many very helpful and persuasive examples - but not referenced with links from the docs?

OK. BTW As a general Question relating to Boost... I was confused for some time as to whether the <libs/examples> and <boost/progheader.hpp> directories are always meant to be in the same relation. Is that laid down anywhere so that headers can be linked in docs?

I didn't spot any examples of ex-Imperial Non-SI units, beloved of the ex-Colonial US ;-)

OK. I will add one :-)

BUT examples would be more helpful with the output shown both inline as comment(s), like

std::cout << angle::rad(angle::deg(180)) <<'\n'; // 3.14159 rad

AND all output appended to the code as a comment, for example:

/*

Output is:

A current of 5 mA through a voltage of 5 V requires a resistance of 1 kR and produces 25 mW of heat total energy used in 1 s is 25 mJ Press any key to continue . . .

*/

OK.

It is very helpful (and worth copying by all Boost authors, especially of examples) that the feature(s) being exemplified (angle) is/are enumerated thus:

using boost::pqs::angle;

angle::rad a = angle::pi;

...

(but sadly often not done this ideal-for-the-reader way!)

OK. One could also argue that all headers required should be included so that copy pasting, then compiling, works. Any feedback on that appreciated...

| - What is your evaluation of the potential usefulness of the library?

Invaluable in most walks of real life. (SI) Units long recognized as a vital library function for Boost.

Yes. This is why I am a bit sad that there havent been some more reviews so far, (and thanks to everyone that has contributed a review). PQS is not a particularly cool ,bleeding edge or *sexy* library but it does come up in everyones everyday life time and again.. There is a lot of potential for standardisation and not reinventing the wheel ( just as with math constants) in this field.

| - Did you try to use the library? Briefly. With what compiler? MSVC 8

Did you have any problems? NO - examples build and run OK.

| - How much effort did you put into your evaluation?

A quick skirmish ;-)

I'd like to see examples of real use in anger - but I fear we may not get that until it is accepted into Boost (chicken/egg problem?).

| - Are you knowledgeable about the problem domain?

Somewhat.

I vote for acceptance.

Great. Thanks Paul!

Paul

PS A few queries:

1 Can value_type include rationals - so that (only) fractional lengths (say) like 1/2, 1/4, 1/8, 3/4, 3/8, 5/4, 9/16 ... could be handled?

Some experimentation suggests that they can but its brittle and needs Boost.Typeof: #include <boost/pqs/typeof_register.hpp> #include <boost/pqs/t1_quantity/types/out/length.hpp> #ifndef BOOST_PQS_USE_BOOST_TYPEOF_BINARY_OPERATION #error need to have Boost.Typeof library and #define BOOST_PQS_USE_BOOST_TYPEOF_BINARY_OPERATION in <boost/pqs/config.hpp> #endif #include <boost/rational.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TEMPLATE(boost::rational, 1); int main() { typedef boost::rational<int> rat; typedef boost::pqs::length_<rat >::in rat_inches; rat_inches length1(rat(1)); rat_inches length2(rat(1,2)); rat_inches result = length1 + length2; std::cout << result << '\n'; } tested in CVC7.1 only however rational +int value_types fails in a horrendous cascade of errors. I dont know if it can be made to work, but its now on the todo list FWIW.

2 If math is the abbreviation for math constants, then physics doesn't match. physical better? Only one letter longer.

Some users have expressed an interest in removing the physic(s)(al) sub namespace altogether so these constants would be in namespace pqs(or whatever it ends up being called) pqs::boltzmanns_constant::K etc. In this case the quantities namespace would stand in for the physic(s)(al) namespace. The rationale being that the form of the constants need the quantities machinery anyway. OTOH maybe phys || physics || physic || physical could replace pqs...

3 dimensionful is a new word on me - dimensioned (opposite of dimensionless).

OK. It look like I'm not going to get away with adding words to the English language :-) Does 'dimensioned' adequately convey "not including dimensionless"? Or is it inclusive of that?

4 It isn't immediately obvious to me how to ensure output in SI 'engineering' multiples, depending on the value. For example, 0.123 m outputs as 1.23 mm, but 1234.5 m outputs as 1.2345 km.

OK. I should document it. As it stands its simply dependent on the current output flags for the quantity value_type, however the whole area of input/output is not adequately documented so far. Thanks again for your review and your vote too. regards Andy Little

Andy Little wrote:

Hi Paul,

"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1FneN9-00014T-OY@he303war.uk.vianw.net...

...

| -----Original Message-----

3 dimensionful is a new word on me - dimensioned (opposite of dimensionless).

OK. It look like I'm not going to get away with adding words to the English language :-)

Does 'dimensioned' adequately convey "not including dimensionless"? Or is it inclusive of that?

I'm not planning to submit a review, but I'd just like to answer this point, if no one has already: "Dimensioned" and "dimensionless" are mutually exclusive. "Dimensioned" means "having a dimension" (eg, the speed of light) and "dimensionless" means "having no dimension" (eg, pi) . These are the words used, and these are the meanings attributed to them, so yes, "dimensioned" adequately conveys "not including dimensionless". Paul

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Giaccone | Sent: 07 June 2006 12:20 | To: boost@lists.boost.org | Subject: Re: [boost] [Review][PQS] Physical Quantities | System review (May31through June 9) | | Andy Little wrote: | > Hi Paul, | > | > "Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message | > news:E1FneN9-00014T-OY@he303war.uk.vianw.net... | > | >> 4 It isn't immediately obvious to me how to ensure output in SI | >> 'engineering' multiples, depending on the value. | >> For example, 0.123 m outputs as 1.23 mm, but 1234.5 m | outputs as 1.2345 km. | >> | | ...and this point too: 0.123 m = 123 mm or 1.23 decametres | (but not 1.23 | mm), so either the above is a bug or incorrectly transcribed. Oops! Shows the need for AUTOMATIC scaling (rather than an incompetent man)! Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Noel Belcourt <kbelco <at> sandia.gov> writes:

I have some questions and general observations for Andy.

I'm not Andy, but I'll make a few comments anyway :-) I implemented a similar library a few years ago for my job, so I think I can help respond to some of your points.

1) Can you give examples of the typical use cases for the proposed t2 and t3 quantities?

In my original review (it's in the thread called "[Review][PQS] Review deadline"), I gave a brief explanation of my use of (the equivalent of) t2_quantity and t3_quantity in my work. Actually, I find the t2_quantity most appropriate for the scientific software I write. As I'll mention below, I think the syntax and use of the t2_quantity can be more intuitive than t1_quantity and alleviates most of the problems you listed below. I almost wish the t2_quantity had been implemented first, and the library might seem less cumbersome to people looking at it for the first time. You can see a brief example in my review of how I envision the syntax would look. In my review I also explained briefly why I have a need for t3_quantity.

5) Is there any way to disable automatic unit conversion? Automatic conversion is a major liability for the scientific community in critical sections of computationally intensive codes and bugs related to this could be very difficult to track down.

6) I appreciate arguments favoring readable code but, in this case, I find that all the unit names (cm_div_s2, km_div_s2, ...) are error prone and likely to reduce code reuse. I'd prefer a solution where I define a unit system, such as the SI system, and then have all quantities in my library use that unit system. This solution makes verifying our algorithms work correctly with more than one unit system very easy, no code changes, and makes it easier to write generic algorithms that are unit independent. The explicit type solution in PQS is, in my opinion, significantly more error prone. Consider this scenario:

In a critical section of code, someone could cause repeated conversions between quantities due to a typing error. A quantity declared cm_div_s2 is, 100 lines down the function, assigned it to a quantity declared km_div_s2. This automatic conversion is tough to catch visually, won't cause a compile error but will cause significant performance and numerical problems.

I believe I understand and share your concerns. And I believe the t2_quantity, as I would envision it (and as I've successfully implemented a similar thing) is precisely meant to address every one of these issues. To explain briefly: For t2_quantity, a length is a length, etc. - there is no separate cm type and km type. Internally, the units are all consistent - say, based on meters, seconds, grams, etc. No actual units conversion takes place in computationally intensive code. Units conversion is only done, essentially, for I/O. If you don't mind a few extra multiplies and divides in your constant declarations, you can write code that looks like this: velocity v1 = 10.0 * cm/s; velocity v2 = 25.0 * km/hr; innstead of having to fuss with names like cm_per_s and km_per_hr. Btw, the same can be done for t3_quantity: t3_quantity v = 10.0 * cm/s; t3_quantity p = 2.0 * kg*m/s; where the dimensions get stored and checked at runtime. (Obviously, this incurs overhead that requires a good reason to justify its use in a particular application.) In my code I address this with a compile-time switch allowing me to turn off the "t3_quantity" dimension-checking, allowing me to eliminate all the overhead for production code, while keeping it for a debugging version. (But now I'm really getting off topic, talking about future parts of the library that don't even exist yet.)

8) Is there an easy way to replace the rational dimensions with integers? A number of disciplines could probably make do with integers and paying for rational dimensions seems expensive and unnecessary, although it's certainly more general.

I suspect (though someone may well correct me!) that fractional dimensions are never strictly necessary, in the sense that the formulas can probably be rewritten to avoid them. For a simple example, if I remember correctly, theperiod of a pendulum with a small range of angular motion is something like sqrt(g/L), where g is an acceleration and L is a length. If code is written like this: const sqrt_accel numer = sqrt(g); ... sqrt_length denom = sqrt(L); time result = numer / denom; then rational dimensions are needed. However, in this case you could also just write something like: time result = sqrt(g/L); which requires no fractional dimensions and takes no additional computation time. Having said that, the additional flexibility doesn't bother me at all if it has no runtime penalty and the details are mostly hidden from the user. If it keeps a software engineer from having to rework a physicists equations, it may well be worth it. -- Leland

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

"Leland Brown" wrote

...

const sqrt_accel numer = sqrt(g); ... sqrt_length denom = sqrt(L); time result = numer / denom;

FWIW the result is a frequency, rather than a time. Nevertheless its a good example !

Oops! Yes, of course. I guess I was too hasty in thinking I knew what I was doing :-) You know, that makes two or three of us now that have made mistakes like this, just in writing example code for the review discussions. I think that points out there really is a need for a library of this kind, to catch all the mistakes made by us sloppy programmers! Thanks for the correction. -- Leland

White noise of all sorts is frequently expressed in terms of the square root of the dimension of interest. V/sqrt(Hz) is probably the most frequently used unit for electrical noise, for example. -Fred Bertsch On 6/8/06, Deane Yang <deane_yang@yahoo.com> wrote:

Leland Brown wrote:

...

I suspect (though someone may well correct me!) that fractional dimensions are never strictly necessary, in the sense that the formulas can probably be rewritten to avoid them.

In earlier discussions, there were a few examples of fractional dimensions provided. The one I am familiar with is called "volatility" in finance but probably has a name like "heat conductance" or "diffusion coefficient" in physics. It is the coefficient c in the heat equation:

u_t = c^2 u_xx

You can see that c has units of length/sqrt(time). You can argue that people should use c^2 directly instead of c (this is analogous to using the variance of a Gaussian in place of the standard deviation), but it *is* very useful to be able to work with c itself.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- F

Leland Brown wrote:

And dare I ask now?... Are half exponents the only fractional ones needed?

I think that's a very good question. I would be very surprised to see a denominator greater than 3 or maybe 4.