Andy, Fred and all Here are my thoughts on the PQS (which I agree is not a good name). Some of them have become redundant since I began jotting them down, but I'll add my voice even though Andy already knows about the issues. I wish I had time to be more complete, but this is all I have time to do at the moment. I also notice that although I was looking at the PDF version of the documentation, there is an html version, that I have not looked at closely enough to have any opinion on whether it is better. About the documentation First an issue of ordering. I think the Getting Started section is quite useful, but it is buried a bit too far into the documents. My guess is that a typical user will want this before anything else, so it should be front and center. This can repair itself when the documents are done as hyper-linked text for a browser instead of a PDF file, since a navigation area can highlight the easy access to this information. Also, the Definition of Terms section is a Glossary, and is probably better placed at the end instead of at the beginning. An understanding of these terms is useful when digging through the details of the library, but not nearly as useful for the causal user. Placed before the Getting Started section, it will make many users wonder if this is going to be too much work for the return. Next one of convenience The Predefined t1_quantities list is not yet very useful. It is also likely to be difficult to maintain, as your list of available units gets longer if it is made useful. What is it missing? A way to decide what is actually available and how to use it. By browsing the headers, I find that in some cases, you have a true wealth of possibilities. Your measures of length include such things as rods and Astronomical Units, for example. (It also includes some things that I don't understand putting in that header (such as acres), but possibly you have a reason for this.) However, the documentation does not yet give me any way to know what the available possibilities are. It also doesn't tell me what the scales are for the various non-SI units, so I have no way to decide that some non-SI unit might better represent the scale of my problem. Unfortunately, fixing this problem will make the documentation quite unwieldy for you to maintain. Just a table listing the name, notation in the pqs and scale for each of the length units would currently have 19 entry rows (counting one for meters, but not including acres or acre-feet). As other units are included, this format is far too likely to be painful for you. I don't yet have a good idea for an alternative, but I think one needs to be found. One about consistency In the Concepts section, you have a reasonable framework for describing each concept. Unfortunately, there are formatting issues that make the concept descriptions hard to follow. The concept names are not differentiated from the subsections of the concept descriptions in a visually obvious way. Some use of a different font size or indentation will make browsing the list for a concept description much easier. The first couple of descriptions have a consistent and complete style, that quickly disappears in the latter concept descriptions. I think this is probably just because you ran out of time for writing them, but I want to make sure it isn't missed latter. About "Getting Started" The pqs includes an all_types.hpp header, that is a one stop include for all of the available types. Unfortunately, I see no place in the documentation where you mention this. Instead, you include long lists of includes when you want to use multiple types. Most new users will probably find this a barrier, since the first concern will be using the library, and only later will the users turn to reducing compile times and sizes (if needed). I think the first couple of examples should just use the all_types.hpp header, and in a later example point out that the user can choose to only include the segments of the library that are needed. Maybe even create an "all_types.hpp" at a higher directory level that includes the types, the I/O capabilities and the whole thing. This is not a good solution for the tightest include lists possible, but it is great for someone who doesn't want to have to figure out which pieces are where for the first few uses of the library. The examples in the Getting Started section are fine for getting the basic uses of the library across. It is clear that the additional typing is minimal and that the code really does become more clear. This could be improved somewhat by showing how to convert a couple of toy calculations in the section. Start from what might have been written originally, and show how it is more readable with minimal intrusion and improved error checking after conversion. Many of the first time users will be people who are struggling with unit problems in a partially constructed code, so make the Getting Started section reflect likely user experiences. About the examples After the Getting Started section, the next place someone is likely to go is the "Examples." I would like to see them accessible from the documentation, with capsule explanations of what is important in each one, so the new user can pick and choose what is important for the current uses. The examples themselves are nice. They just need an easy entry for the user. About the implementation The implementation appears reasonable, though I have not been able to put the time into it that would be required to understand all of the details. My primary issue is with the attachment between specific units and prefixes. For example, in the length units, the prefixes for powers of ten are connected only to the meters units. In my work, attaching them to other units (such as MeV for mega electron volts or Gpc for Giga-parsecs) is quite common. Without developing a detailed understanding of the implementation, I have no suggestion for how to decouple the prefixes from the specific units, but it is a question worth considering. The prefixes are in common use with a wide range of base units, so some method of decoupling strikes me as a good choice. In use, the impact of the names for the quantities is not a problem for me. There is increased typing in some places, but the added clarity and the reduced need for additional descriptive comments in the code convince me that it is worth it. My use of the library I only had a couple of hours to give to this, so I did not get to do anything more than read the documentation, skim the implementation and try a few of the examples. I would like to rework a couple of pieces of simulation code to use this, but I just can't give that time at the moment. From my small experience of it, I think it is a good starting place. In compiling the examples, I have had a few issues. I'm waiting to report them until I have the time to formulate a small example that displays them, or even better to find the problem. I get compiler errors in some cases, using OSX 10.3.9 and gcc 3.3. My one request I think this will become a reality with the addition of the type_of library, but I strongly request an easy way to add new units. In my work writing physical simulations, most of the time I use simulation units instead of any standard physical unit. This is done for the usual reason of keeping the numbers in the calculation as close to order 1 as possible, to minimize the numeric issues. Only rarely is there a convenient physical unit for this, so simulation units and various dimensionless quantities are the rule for me. As such, I will often have the need to define new units when using this system, so I would like it to be as simple as possible. My understanding of the problem domain I have a reasonable understanding of the issues encountered while writing physical simulations, and only a passing understanding of the implementation issues involved in writing a library of this sort. Recommendation I am in favor of including this library in Boost. As noted above, there are issues I would like to see addressed, but on the whole I think this is a good piece of work and fills a very large need in the computational science and engineering community. John Phillips
Hi John, "John Phillips" wrote
Andy, Fred and all Here are my thoughts on the PQS (which I agree is not a good name). Some of them have become redundant since I began jotting them down, but I'll add my voice even though Andy already knows about the issues. I wish I had time to be more complete, but this is all I have time to do at the moment. I also notice that although I was looking at the PDF version of the documentation, there is an html version, that I have not looked at closely enough to have any opinion on whether it is better.
FWIW, the pdf version was only intended to complement the html version, to help if anyone wanted to print it. It being automatically generated without much thought, there is a lot wrong with it including poor format and broken links. It is clear though that it was a popular download !
About the documentation
First an issue of ordering. I think the Getting Started section is quite useful, but it is buried a bit too far into the documents. My guess is that a typical user will want this before anything else, so it should be front and center. This can repair itself when the documents are done as hyper-linked text for a browser instead of a PDF file, since a navigation area can highlight the easy access to this information.
Yes, many reviews have said similarly.
Also, the Definition of Terms section is a Glossary, and is probably better placed at the end instead of at the beginning. An understanding of these terms is useful when digging through the details of the library, but not nearly as useful for the causal user. Placed before the Getting Started section, it will make many users wonder if this is going to be too much work for the return.
FWIW my review manager, suggested moving the Glossary to the back before the review started, but I knew better at the time! but yes, it looks like it should be at the back.
Next one of convenience The Predefined t1_quantities list is not yet very useful. It is also likely to be difficult to maintain, as your list of available units gets longer if it is made useful. What is it missing? A way to decide what is actually available and how to use it.
This is dependent on whether you use the pdf or html docs. If you look in the html docs they should provide the information on units.
By browsing the headers, I find that in some cases, you have a true wealth of possibilities. Your measures of length include such things as rods and Astronomical Units, for example. (It also includes some things that I don't understand putting in that header (such as acres), but possibly you have a reason for this.)
I do... I mistakenly added acres in my local database as a length unit as well as an area unit. The file generation machinery has faithfully reproduced it in docs and headers.
However, the documentation does not yet give me any way to know what the available possibilities are. It also doesn't tell me what the scales are for the various non-SI units, so I have no way to decide that some non-SI unit might better represent the scale of my problem. Unfortunately, fixing this problem will make the documentation quite unwieldy for you to maintain. Just a table listing the name, notation in the pqs and scale for each of the length units would currently have 19 entry rows (counting one for meters, but not including acres or acre-feet). As other units are included, this format is far too likely to be painful for you. I don't yet have a good idea for an alternative, but I think one needs to be found.
As regards what represents completeness the aim is to include all and only the quantities and units listed in appendix B8 and B9 of the Guide for the International System of Units.
One about consistency In the Concepts section, you have a reasonable framework for describing each concept. Unfortunately, there are formatting issues that make the concept descriptions hard to follow. The concept names are not differentiated from the subsections of the concept descriptions in a visually obvious way. Some use of a different font size or indentation will make browsing the list for a concept description much easier. The first couple of descriptions have a consistent and complete style, that quickly disappears in the latter concept descriptions. I think this is probably just because you ran out of time for writing them, but I want to make sure it isn't missed latter.
Yes. the entire Concepts section needs to be restarted.
About "Getting Started" The pqs includes an all_types.hpp header, that is a one stop include for all of the available types. Unfortunately, I see no place in the documentation where you mention this. Instead, you include long lists of includes when you want to use multiple types. Most new users will probably find this a barrier, since the first concern will be using the library, and only later will the users turn to reducing compile times and sizes (if needed). I think the first couple of examples should just use the all_types.hpp header, and in a later example point out that the user can choose to only include the segments of the library that are needed. Maybe even create an "all_types.hpp" at a higher directory level that includes the types, the I/O capabilities and the whole thing. This is not a good solution for the tightest include lists possible, but it is great for someone who doesn't want to have to figure out which pieces are where for the first few uses of the library.
The problem is that the number of quantities in all_types.hpp could get very large. The first effect is slow compilation. The second is the compiler running out of storage, or indices or keys or whatever, so though I understand the point I am slightly wary of doing this. The other issue is that slow compilation reflects badly on the library, especially for first time users.
The examples in the Getting Started section are fine for getting the basic uses of the library across. It is clear that the additional typing is minimal and that the code really does become more clear. This could be improved somewhat by showing how to convert a couple of toy calculations in the section. Start from what might have been written originally, and show how it is more readable with minimal intrusion and improved error checking after conversion. Many of the first time users will be people who are struggling with unit problems in a partially constructed code, so make the Getting Started section reflect likely user experiences.
OK. It is difficult to pick the right level. I should maybe also add some info or links regarding units , dimensional analysis and so on.
About the examples After the Getting Started section, the next place someone is likely to go is the "Examples." I would like to see them accessible from the documentation, with capsule explanations of what is important in each one, so the new user can pick and choose what is important for the current uses.
Yes. That should be added.
The examples themselves are nice. They just need an easy entry for the user.
OK.
About the implementation
The implementation appears reasonable, though I have not been able to put the time into it that would be required to understand all of the details. My primary issue is with the attachment between specific units and prefixes. For example, in the length units, the prefixes for powers of ten are connected only to the meters units. In my work, attaching them to other units (such as MeV for mega electron volts or Gpc for Giga-parsecs) is quite common. Without developing a detailed understanding of the implementation, I have no suggestion for how to decouple the prefixes from the specific units, but it is a question worth considering. The prefixes are in common use with a wide range of base units, so some method of decoupling strikes me as a good choice.
The library only deals in SI units and not natural units, except in their relation to SI units and as constants expressed in SI units. This is a weakness of the library, but reflects the fact that I have no experience in natural units or other unit systems and how they are combined and operate. I am aware that Walter Browns original SI units could be used with various unit systems and units could even be converted between them, but in PQS I have (rightly or wrongly ) opted to only cover SI units to limit the scope of the project to something manageable. I realise that this is disappointing however there are enough problems within one system ( such as the problem of linear algebra on quantities discussed in another thread), that I would prefer to solve them satisfactorily for one system rather than try to create a half-finished solution to cover every system. The most pertinent question that I dont know the answer to is whether there are benefits in practise to using physical quantities in large scale systems over using floating point types or not. It may well be that using quantities is impractical for various reasons (incompatibility of libraries, compilation times) or others unknown as yet. I should however try to ensure that the library can potentially be extended to other unit systems as far as possible, and currently it is weak in that area.
In use, the impact of the names for the quantities is not a problem for me. There is increased typing in some places, but the added clarity and the reduced need for additional descriptive comments in the code convince me that it is worth it.
Yes. At least in simple use the library does seem to be a win over use of traditional floats.
My use of the library
I only had a couple of hours to give to this, so I did not get to do anything more than read the documentation, skim the implementation and try a few of the examples. I would like to rework a couple of pieces of simulation code to use this, but I just can't give that time at the moment. From my small experience of it, I think it is a good starting place. In compiling the examples, I have had a few issues. I'm waiting to report them until I have the time to formulate a small example that displays them, or even better to find the problem. I get compiler errors in some cases, using OSX 10.3.9 and gcc 3.3.
OK. The library could benefit from the substantial Boost test infrastructure if accepted too.
My one request
I think this will become a reality with the addition of the type_of library, but I strongly request an easy way to add new units. In my work writing physical simulations, most of the time I use simulation units instead of any standard physical unit. This is done for the usual reason of keeping the numbers in the calculation as close to order 1 as possible, to minimize the numeric issues.
Having spent time with SI units, I am unclear what you mean. Is it possible to demonstrate with an example?
Only rarely is there a convenient physical unit for this, so simulation units and various dimensionless quantities are the rule for me. As such, I will often have the need to define new units when using this system, so I would like it to be as simple as possible.
OK. I am ware that the whole rigmarole involved in defining types and units could be improved. Composition with Boost Typeof would help as well as improved Concept docs perhaps.
My understanding of the problem domain
I have a reasonable understanding of the issues encountered while writing physical simulations, and only a passing understanding of the implementation issues involved in writing a library of this sort.
Recommendation
I am in favor of including this library in Boost. As noted above, there are issues I would like to see addressed, but on the whole I think this is a good piece of work and fills a very large need in the computational science and engineering community.
Great. I suspect that the answers I gave arent totally satisfactory, especially regarding moving beyond the SI system, but at least I shall try to make PQS extensible to other systems Thanks for your review. regards Andy Little
Andy Little wrote:
I am aware that Walter Browns original SI units could be used with various unit systems and units could even be converted between them, but in PQS I have (rightly or wrongly ) opted to only cover SI units to limit the scope of the project to something manageable. I realise that this is disappointing however there are enough problems within one system ( such as the problem of linear algebra on quantities discussed in another thread), that I would prefer to solve them satisfactorily for one system rather than try to create a half-finished solution to cover every system.
There's a big difference between providing flexibility in the design and actually using that flexibility to implement everything. I would be perfectly happy with a library that provided flexibility for other units (decoupling prefixes, allowing non-power-of-10 prefixes, etc.) but only actually implemented SI units. Just as t2_quantity and t3_quantity can come later, so can other units systems.
I should however try to ensure that the library can potentially be extended to other unit systems as far as possible, and currently it is weak in that area.
I would like that very much. I'm willing to help in whatever way possible. Would it help to gather a list of flexibility requirements? The Boost Wiki would be a good place for that.
OK. I am ware that the whole rigmarole involved in defining types and units could be improved. Composition with Boost Typeof would help as well as improved Concept docs perhaps.
I actually didn't find this too intimidating, but then I've done a fair amount of TMP. Of course, if it can be improved, all the better! -Dave
"David Greene" wrote
Andy Little wrote:
I should however try to ensure that the library can potentially be extended to other unit systems as far as possible, and currently it is weak in that area.
I would like that very much. I'm willing to help in whatever way possible. Would it help to gather a list of flexibility requirements? The Boost Wiki would be a good place for that.
Maybe, except is it a lot of work to maintain a Wiki? Anyway wherever its put, a list of requirements, unit concepts and even quantity and unit systems that should be modelled would certainly be very useful. regards Andy Little
Andy Little said: (by the date of Sun, 11 Jun 2006 10:58:48 +0100)
"David Greene" wrote
Andy Little wrote:
I should however try to ensure that the library can potentially be extended to other unit systems as far as possible, and currently it is weak in that area.
I would like that very much. I'm willing to help in whatever way possible. Would it help to gather a list of flexibility requirements? The Boost Wiki would be a good place for that.
Maybe, except is it a lot of work to maintain a Wiki? Anyway wherever its put, a list of requirements, unit concepts and even quantity and unit systems that should be modelled would certainly be very useful.
Yes, I think that after so much, and so lenghty discussion it may be a very good point to start a wiki. All people contributing in this discussion will be interested in writing specifications for expected libraries. Libraries, because I currently see three decupled libraries emerging from all of this: 1. Dimensions (idea from Oleg Abrosimov) to decuple this perhaps here should be included the ability to use different powers for dimension scaling: powers of ten or powers of two. Also Noel Belcourt may have something interesting to say about this, because he plans to show us uncomplicated solution demonstrating support for user selectable integer and rational dimensions. 2. Units (with example implemetation of some particular system - eg. SI ;) 3. vector/matrix/quaternion with support for units - but how to call this library? I would seriously recommend against calling it geometry. Because this library will not support circles, ellipses, polylines or any other geometrical shapes - that would be siply too much for the beginning! Better start with something simple that has at least a vague possibility of being implemented at all! Remember - specification is one thing, we can define even a very complex library with all geometrical shapes, but who will implement all that? Of course I want to help with that, but we all have limited time. So better limit this only to vector/matrix/quaternion. How to call it then? "Blas" would be confused with Ublas (already a boost library). Algebra ? LinearAlgebra ? -- Janek Kozicki |
--- Janek Kozicki <janek_listy@wp.pl> wrote:
I currently see three decupled libraries emerging from all of this:
1. Dimensions (idea from Oleg Abrosimov) to decuple this
<snip>
2. Units (with example implemetation of some particular system - eg. SI ;)
3. vector/matrix/quaternion with support for units
I agree - this is a great way to divide up the parts of the library, and hopefully these can be largely independent yet work together. -- Leland __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Leland Brown wrote:
--- Janek Kozicki <janek_listy@wp.pl> wrote:
I currently see three decupled libraries emerging from all of this:
1. Dimensions (idea from Oleg Abrosimov) to decuple this
<snip>
2. Units (with example implemetation of some particular system - eg. SI ;)
3. vector/matrix/quaternion with support for units
I agree - this is a great way to divide up the parts of the library, and hopefully these can be largely independent yet work together.
-- Leland
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think we should try to stay out of the business of making a linear algebra system (or a tensor algebra system, either, for that matter) on this project. Careful though should be given to the interaction between the units system and popular algorithms for doing algebraic manipulations, but that should be the extent of it for now. Otherwise, we have a small and probably otherwise busy group of people trying to do a collection of very large jobs all at once. This doesn't strike me as a recipe for success. John Phillips
On 2006-06-20, John Phillips <phillips@delos.mps.ohio-state.edu> wrote:
I think we should try to stay out of the business of making a linear algebra system (or a tensor algebra system, either, for that matter) on this project.
I concur. I was already concerned with the size of PQS - recent discussions have made me distinctly worried. PQS should do roughly what it says on the tin: dimensional analysis and units. Do it small, do it tidily, do it clean. It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-) phil -- change name before "@" to "phil" for email
Phil Richards wrote:
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-)
More than that - I believe its the only way something like this (which is really needed) is going to get into boost at all. I think that it would be best to start with a dimensional analysis library and not worry about units at all until latter. I subsequent units library - there might be several would be built as "users" of the dimensional analysis library. This way, there would be a lot less to try to agree upon. layer 1 dimensional analysis core layer 2 specific dimension systems - usages of the above library - probably more than one layer 3 units core - extension of dimensional analysis library layer 4 specifice units systems. Now I know from experience that lots of people will find say - "if it doesn't include xyz... its just useless". Well, those people are wrong. If sufficient number of people find the lower levels useful, it can accepted eventhough not eveyone wants to use it. Also it would make the library(ies) much easier to understand and use. Robert Ramey
On 2006-06-21, Robert Ramey <ramey@rrsd.com> wrote:
Phil Richards wrote:
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-) More than that - I believe its the only way something like this (which is really needed) is going to get into boost at all.
I agree with that too. [the stages to a solution...]
layer 1 dimensional analysis core
Yep.
layer 2 specific dimension systems - usages of the above library - probably more than one
Probably need to do 1 and 2 together - otherwise the library is practically useless. Demonstrate that layer 1 works with a layer 2 SI implementation (the one that the majority of people would want, I suspect), but with a clear example of how other variants can work.
layer 3 units core - extension of dimensional analysis library
This is one where I've been having a hard think. I think it is possible to have units done independently of DA. When units are applied to a dimensioned value, then various smarts can kick in to do with multiplication and division, but there's a lot that can be done with just addition, subtraction and scaling (I wish my Maths degree wasn't 20 years ago or I'd remember the proper name for this type of space). In particular, we could make sure that absolute+relative (point+vector, or whatever else you want to call it) stuff works cleanly. (i.e., the difference between conversion of a temperature difference of 1C being 1.8F, and 0C being 32F.)
layer 4 specifice units systems.
Similar comment to layer 2.
Now I know from experience that lots of people will find say - "if it doesn't include xyz... its just useless". Well, those people are wrong.
Agreed.
Also it would make the library(ies) much easier to understand and use.
And on this too. phil -- change name before "@" to "phil" for email
"Phil Richards"software.demon.co.uk...
On 2006-06-20, John Phillips <phillips@delos.mps.ohio-state.edu> wrote:
I think we should try to stay out of the business of making a linear algebra system (or a tensor algebra system, either, for that matter) on this project.
I concur. I was already concerned with the size of PQS - recent discussions have made me distinctly worried. PQS should do roughly what it says on the tin: dimensional analysis and units. Do it small, do it tidily, do it clean.
That is all very well Phil. Now where's the code?. Actually I know you have written some code. I would be interested naturally to see it. What happens when you start a quantities library is that you suddenly find the problems are a bit bigger than you thought. The dimensional analysis part is frankly trivial. The bloat you talk about is the result of going into detail that previous libraries ignored: User interface, units and basic input/output. It is only when you start to look at that in detail that you find things such as you need to distinguish different but dimensionally equivalent quantities, rational powers, the weirdness of the kilogram etc, etc, etc, etc. Other libraries left these 'trivial' details to the user to sort out. That is a mistake IMO IMO the other problem that previous libraries had was that they assumed that using mpl was mandatory. This brings up a simple but practical problem. In this environment mpl is darn slow. The practical effect of that is that your development is slowed to a crawl. I used mpl in PQS and it was impractical, so I removed it. I did so with a heavy heart because I was aware that doing so would probably kill PQS as a boost library I mean if the problems were trivial boost would have its quantities library by now wouldnt it?
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-)
Are you saying that PQS doesnt do that? The signature of the t1_quantity is t1_quantity<abstract_quantity, unit, value_type> That looks like quite a clear separation of concerns to me FWIW. Am I missing something? regards Andy Little
On 2006-06-23, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
I concur. I was already concerned with the size of PQS - recent discussions have made me distinctly worried. PQS should do roughly what it says on the tin: dimensional analysis and units. Do it small, do it tidily, do it clean. That is all very well Phil. Now where's the code?. Actually I know you have written some code. I would be interested naturally to see it.
Well, even so, I think your comment is a little bit unfair given that I have implemented most of what I've talked about in the past. I still think that PQS at 24,000 lines of code is rather on the heavy side. And all the talk I've seen is about adding more. BUt I might have missed something. It's been a long thread.
What happens when you start a quantities library is that you suddenly find the problems are a bit bigger than you thought.
Probably don't need to remind me of that...
The dimensional analysis part is frankly trivial. The bloat you talk about is the result of going into detail that previous libraries ignored: User interface, units and basic input/output.
Done basic input/output. Done *simple* units conversion (and I admit, it is nowhere near to the depth you did - and I like the ideas behind what you have done in that area, but that doesn't mean that a functionally equivalent solution to yours couldn't be achieved). Not sure what "user interface" is and I'd probably say it was subjective anyway.
IMO the other problem that previous libraries had was that they assumed that using mpl was mandatory. [...] I did so with a heavy heart because I was aware that doing so would probably kill PQS as a boost library
Don't really think it is a killer. I've done it both ways - the MPL took a lot of effort to get anywhere near reasonable compile-time performance, and even then it was at least a factor of 2 slower. So, I agree with you about not using
I mean if the problems were trivial boost would have its quantities library by now wouldnt it?
Erm, yes. One of the reasons I gave up on this whole thing (in Boost) was simply that trying to get measurable/achievable requirements was rather hard. And I can't solve problems in domains for which I have no experience without some practical use-cases.
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-) Are you saying that PQS doesnt do that?
Perhaps I should have used "independent" rather than "orthogonal".
The signature of the t1_quantity is t1_quantity<abstract_quantity, unit, value_type> That looks like quite a clear separation of concerns to me FWIW. Am I missing something?
Yes. It should (ideally) be something like: dimensioned<value_type, dimension> united<value_type, unit> for any "reasonable" value_type (and both united and dimensioned would be "reasonable"). Or some such. If you only want dimensionality checking, you can have it without units. If you only want units, you can have it. If you want both, you stack them. (united<dimensioned<value_type, dimension>, unit>) Yes, I know it's not that easy. And it might even require typeof to be even slightly achievable, so might even be a non-starter. I just wish I had time to have a play with it :-) As you imply, unless I'm willing to code it, I really should shut up. So I will. phil -- change name before "@" to "phil" for email
"Phil Richards" wrote
On 2006-06-23, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
I concur. I was already concerned with the size of PQS - recent discussions have made me distinctly worried. PQS should do roughly what it says on the tin: dimensional analysis and units. Do it small, do it tidily, do it clean. That is all very well Phil. Now where's the code?. Actually I know you have written some code. I would be interested naturally to see it.
Well, even so, I think your comment is a little bit unfair given that I have implemented most of what I've talked about in the past.
You are criticising my work. I believe you have been unfair. You say you can do better . Its only reasonable to expect a demo isnt it?
I still think that PQS at 24,000 lines of code is rather on the heavy side. And all the talk I've seen is about adding more. BUt I might have missed something. It's been a long thread.
I havent calculated in terms of Klocs, but (if you have a copy of pqs_3_1_1), you could look at the <boost/pqs/t1_quantity/types> directory. You should also add in the <boost/pqs/meta/components> directory, the two_d,three_d, angle and utility stuff. That adds up to around 2/3 of the total code size on my local disc AFAICS. That comprises what I call User interface.
What happens when you start a quantities library is that you suddenly find the problems are a bit bigger than you thought.
Probably don't need to remind me of that...
The dimensional analysis part is frankly trivial. The bloat you talk about is the result of going into detail that previous libraries ignored: User interface, units and basic input/output.
Done basic input/output. Done *simple* units conversion (and I admit, it is nowhere near to the depth you did - and I like the ideas behind what you have done in that area, but that doesn't mean that a functionally equivalent solution to yours couldn't be achieved).
Not sure what "user interface" is and I'd probably say it was subjective anyway.
User interface is first the convenient typedefs with units, second the supporting classes for physical quantities in space, as I mentioned above.. Physical quantities is a brave new world from floats.
IMO the other problem that previous libraries had was that they assumed that using mpl was mandatory. [...] I did so with a heavy heart because I was aware that doing so would probably kill PQS as a boost library
Don't really think it is a killer. I've done it both ways - the MPL took a lot of effort to get anywhere near reasonable compile-time performance, and even then it was at least a factor of 2 slower. So, I agree with you about not using.
OK, and I think its worth pointing out for anyone developing their own units library. Its another hurdle for me because its a central theme in the TMP book. Its also an underlying reason for rejection of PQS AFAICS. The myth continues ....
I mean if the problems were trivial boost would have its quantities library by now wouldnt it?
Erm, yes. One of the reasons I gave up on this whole thing (in Boost) was simply that trying to get measurable/achievable requirements was rather hard. And I can't solve problems in domains for which I have no experience without some practical use-cases.
I rest my case ..................;-)
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-) Are you saying that PQS doesnt do that?
Perhaps I should have used "independent" rather than "orthogonal".
The signature of the t1_quantity is t1_quantity<abstract_quantity, unit, value_type> That looks like quite a clear separation of concerns to me FWIW. Am I missing something?
Yes. It should (ideally) be something like: dimensioned<value_type, dimension> united<value_type, unit> for any "reasonable" value_type (and both united and dimensioned would be "reasonable"). Or some such.
In practise what this means is that the user needs to deal with the united_value. That means either a special case for quantities that use it as a value_type or rewriting sin, cos, and everything in <cmath> FWIW. Feel fee to do that if you wish ;-) The underlying reason is that there is no such thing as a quantity without units FWIW.
If you only want dimensionality checking, you can have it without units. If you only want units, you can have it. If you want both, you stack them. (united<dimensioned<value_type, dimension>, unit>)
Yes, I know it's not that easy. And it might even require typeof to be even slightly achievable, so might even be a non-starter. I just wish I had time to have a play with it :-)
As you imply, unless I'm willing to code it, I really should shut up. So I will.
No offence intended Phil, I know you have done a lot of work in this area. Its a shame you didn't get time to do a review. I would have been interested in that. Again.. Congrats on the baby ! regards Andy Little
participants (7)
-
Andy Little -
David Greene -
Janek Kozicki -
John Phillips -
Leland Brown -
Phil Richards -
Robert Ramey