Is the dimensional analisys code shown in the MPL tutorial, part of the mpl library ? Or any other boost library ?
Sérgio Vale e Pace <svpace.forum@gmail.com> writes:
Is the dimensional analisys code shown in the MPL tutorial, part of the mpl library ? Or any other boost library ?
Nope. People who are serious about dimensional analysis seem to want several capabilities not provided by that code, such as fractional exponents. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Is there any current efford to develop that? the fractional exponents solution has been presented in the Walter Brown´s paper. There is already a requirement set for such library? there is interest in such library? On Thu, 27 Jan 2005 18:11:53 -0500, David Abrahams <dave@boost-consulting.com> wrote:
Sérgio Vale e Pace <svpace.forum@gmail.com> writes:
Is the dimensional analisys code shown in the MPL tutorial, part of the mpl library ? Or any other boost library ?
Nope. People who are serious about dimensional analysis seem to want several capabilities not provided by that code, such as fractional exponents.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2005-01-28, Sérgio Vale e Pace <svpace.forum@gmail.com> wrote:
Is there any current efford to develop that? the fractional exponents solution has been presented in the Walter Brown´s paper. There is already a requirement set for such library? there is interest in such library?
Might I suggest that you have a look at the boost developer mailing list archives for "dimensional analysis" and/or "physical quantities"? (Or bits of those phrases, anyway.) I'm still recovering from the last discussion about a year or so ago... I still twitch when I hear "dimensional analysis" and "angle" in the same sentence. Simple answer: there were at least three approaches being talked about a while back, but all of them had perceived limitations by some. I don't think it was ever agreed what such a library should actually be capable of - which makes it rather difficult to satisfy everybody :-) My solution did/does use the MPL (now, anyway), and has fractional powers, but so did at least one of the others. I'm using it in a "proper" (real-world) project, and it does what we need. But I no longer have the time to try and put it forward here - maybe when the baby has grown up a bit :-) phil -- change name before "@" to "phil" for email
"Phil Richards" <news@derived-software.ltd.uk> wrote On 2005-01-28, Sérgio Vale e Pace <svpace.forum@gmail.com> wrote:
Is there any current efford to develop that? the fractional exponents solution has been presented in the Walter BrownŽs paper. There is already a requirement set for such library? there is interest in such library?
Yes, but dimensional -analysis is only one part. The real issue is physical quantities and units, which is a much more involved and messy subject. IMO the niche is for those who need to deal with physical quantities on a day to day basis. This involves dealing with units and angles, maths and matrices etc, using the stronger type checking. (There is also a large amount of disagreement on various issues, best resolved simply by use cases than argument on boost... eg over angles.) A familiar example of the problem of coding with physical quantities is screen coordinates. These are in fact lengths, whereas in GUI's an int (or double) pixel (or 'logical-coordinate') type is often used for drawing. Its a paradigm shift and would have a major impact on code which is not backward compatible. Then again, a few people seem to 'get it' ... ;-)
I'm still recovering from the last discussion about a year or so ago... I still twitch when I hear "dimensional analysis" and "angle" in the same sentence.
FWIW angle is a value_type in my version. (IMO angle is not a dimension) :-) http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/angles.html with (only in case of 'irrational' angles) implicit conversion( or 'decay') to/from an arithmetic type. (Not documented above but available in the lib) This allows it to work with arithmetic types, passing eg radians while trapping errors involving attempted conversion of eg degrees... works well IMO. (BTW code tested on gcc3.3, VC7.1. I have done some work compatibility issues with later gcc versions (eg gcc3.3). If interested email me privately for patches)
My solution did/does use the MPL (now, anyway), and has fractional powers, but so did at least one of the others.
I would ideally like to redo pqs using 'official boost' but currently dont have time. Firstly would be nice to have boost::mpl::rational_c completed ( "boost/mpl/math/rational_c.hpp"), which AFAIK is in progress. Secondly return type deduction plays a major role. So another requirement would be Arkadiy Vertleybs type deduction lib. With those components in place things would be simpler.
I'm using it in a "proper" (real-world) project, and it does what we need.
As do I ... I simply wouldnt go back to using doubles.
maybe when the baby has grown up a bit :-)
I agree. In reality a 'useful' physical quantities library would be big. This needs a lot of time and work to mature. regards Andy Little
The fact that units is required and important shouldn't inhibit the utility of a dimensional analysis library. Ideally, a units library would depend on a dimensional analysis library. But a dimensional analysis library should be able to stand on its own. I'm aware that efforts to agree on a units library have failed to reach a consensus. But perhaps its might be possible that a consensus could be reached on a dimensional analysis library? That would be a good first step and useful in its own right. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> wrote in message news:cte66r$gt9$1@sea.gmane.org...
I'm aware that efforts to agree on a units library have failed to reach a consensus. But perhaps its might be possible that a consensus could be reached on a dimensional analysis library? That would be a good first step and useful in its own right.
Yes the dimensional analysis is in practise simple and well known , (due to Walter Brown, David Abrahams/AlexeiGurtovoys et al's code) and could presumably be finalised, but it needs implementation of a compile time rational eg boost::mpl::rational_c ( I think Cromwell Enage is working on this?), (with some compiletime operators.),which is a 'building block' for it. I assume that the rational impl could then plug straight in to the mpl book code ? regards Andy Little
On 2005-01-28, Robert Ramey <ramey@rrsd.com> wrote:
The fact that units is required and important shouldn't inhibit the utility of a dimensional analysis library. Ideally, a units library would depend on a dimensional analysis library. But a dimensional analysis library should be able to stand on its own.
Indeed it does. I use one every day... we don't care about unit conversions because we don't do any. We also don't care about anything but 4 of the dimensions, so that's all we use. (We could use more - it is just an mpl::vector of fractional powers.) Still, as I said, agreement couldn't be achieved last time round on pretty much anything, and life is too short to discuss whether angle should, or shouldn't, be able to be treated as a dimension that sometimes is, or isn't, dimensionless... *shudder* phil -- change name before "@" to "phil" for email
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050129141037.DE6D0E305@derisoft.derived-software.demon.co.uk...
On 2005-01-28, Robert Ramey <ramey@rrsd.com> wrote:
The fact that units is required and important shouldn't inhibit the utility of a dimensional analysis library. Ideally, a units library would depend on a dimensional analysis library. But a dimensional analysis library should be able to stand on its own.
Indeed it does. I use one every day... we don't care about unit conversions because we don't do any.
I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
We also don't care about anything but 4 of the dimensions, so that's all we use. (We could use more - it is just an mpl::vector of fractional powers.)
With pqs I was trying to create a concrete type. IOW I was very preoccupied with making a simple user-interface. I go back to the example of std::string. (which is an interface). Whatever its faults I dont want in general to create my own allocators or char types every time use it. So though I accept the idea of customising the number of *base-units* [1] , for a widely useable set of physical quantities types a default the 7 in the S.I. system are required. The *unused* base-units increase compile times and lengthen the signature for error messages, but because of its universality this is worth it. I opted not to use a mpl::vector, rather each base-unit is given its own type, which is more understandable in error messages. Again this is due to a concern with the user-interface.
Still, as I said, agreement couldn't be achieved last time round on pretty much anything,
This seems to be a pessimistic view of what went on IMO. Is it not up to the librray designed to come up with a solution based on the discussions. I incorporated some things from these discussions into pqs. However I have always had a very specific view of what I want from a physical_quantities library, which has naturally had a major influence on the design. Some things that came up were * Fractional dimensional-exponents. * What is the result type from a calculation of dimennsionally-equivalent types but of different units. * How do you distinguish dimensionally equivalent but different quantities. * Angles (One not dealt with yet is centigrade) Another frequent point was "money as a physical quantity". Money is not a physical quantity, Nevertheless there is a place for another type, built on the building blocks of currency and physical quantities: area::m2 wall_area(length * height); apply<divides,currency::dollars,area::m2>::type cost_per_sq_m ; // <-- here in >> cost_per_sq_m; currency::dollars cost =cost_per_sq_m * wall_area; However this presupposes the currency and physical quantities libraries For all these things A universal operator type deduction mechanism is required, while waiting for decltype. BOOST_DECLTYPE may provide the interface but there needs to be an underlying framework too. May still be reqd after decltype too.
and life is too short to discuss whether angle should, or shouldn't, be able to be treated as a dimension that sometimes is, or isn't, dimensionless...
Though if there was to be a boost version, unfortunately this would need to be thrashed out. And that is the problem. It is a big project. I would ideally like to 'boostify' pqs but dont have time currently. However Robert Rameys idea to do the dimensional anlysis library alone seems good, as it is less contentious and surely would not be too much work Still requires generic operator result_type deduction though, whether based on mpl, result_of, BOOST_DECLTYPE, lambda lib,spirit or whatever... [1] ( FWIW The term dimensions is incorrectly used here. According to S.I. the correct terminology is dimension of the systems base units)
On 2005-01-30, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050129141037.DE6D0E305@derisoft.derived-software.demon.co.uk... [wrt dimensional analysis being independent from units]
Indeed it does. I use one every day... we don't care about unit conversions because we don't do any. I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
Yes, but I think what is being raised is that a "physical quantities library" and a "dimensional analysis library" don't have to be the same thing. The latter is a much simpler proposition, and, for many people is all that they want. It's all we need because *all* our interfaces to the outside world are defined entirely in terms of SI units. We make unit conversion an SEP[*]. (Yes, there is an optional bolt-on that supports unit conversion, but we don't need to use it so we don't.) phil [*] somebody else's problem -- change name before "@" to "phil" for email
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050130142206.305CF5C14@derisoft.derived-software.demon.co.uk...
On 2005-01-30, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050129141037.DE6D0E305@derisoft.derived-software.demon.co.uk... [wrt dimensional analysis being independent from units]
Indeed it does. I use one every day... we don't care about unit conversions because we don't do any. I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
Yes, but I think what is being raised is that a "physical quantities library" and a "dimensional analysis library" don't have to be the same thing. The latter is a much simpler proposition, and, for many people is all that they want.
Strictly speaking dimensional-analysis is only used for checking (what I have called) 'abstract quantities'. As soon as a value is involved you need units in order to decipher what the value means. Therefore IMO a dimensional analysis type should not have a Runtime 'value' member and should be limited to compile time only. Then the dimensional analysis part can certainly be separated out as a self contained module. The two requirements on it would be some form of compile time math operations and also ideally some useful error message scheme on invalid operations. One could then roll ones own physical-quantity with that as a building block as reqd I guess.
It's all we need because *all* our interfaces to the outside world are defined entirely in terms of SI units. We make unit conversion an SEP[*].
IOW you are a user node on a generic physical quantities hub ... Let pqs take the strain ... :-) [*] That somebody else is me I guess.. no problem. However I hear what you are saying re boost::dimensional_analysis. regards Andy Little
On 2005-01-30, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
Strictly speaking dimensional-analysis is only used for checking (what I have called) 'abstract quantities'. As soon as a value is involved you need units in order to decipher what the value means. Therefore IMO a dimensional analysis type should not have a Runtime 'value' member and should be limited to compile time only.
The dimensionality can be factored off into its own (compile-time) checked chunk. To be usable there will need to be something that uses it with a value type and delegates down all operations to that underlying value type. This is rather similar to the approach taken by Matthias Schabel (apologies if I've got the spelling or name wrong), but had unit checking as an extra field on the wrapper type. It is also similar to the approach I use... The type wrapper type in my library is something like: template< typename ValueType, typename Dimensionality, typename Units = no_units > class quantity; Etc, etc. Robert's comment about the amount of effort to get everything together for a boost library is pertinent - I don't have the time to do even the cut down version to a suitably high standard for boost. [... other stuff I pretty much agree with elided ...] [I said:]
It's all we need because *all* our interfaces to the outside world are defined entirely in terms of SI units. We make unit conversion an SEP[*]. IOW you are a user node on a generic physical quantities hub ... Let pqs take the strain ... :-)
The point is we don't need anybody to take the strain because their isn't any. Unit conversion and/or unit enforcement just isn't done. Anywhere. At all. Ever. We just want dimensionality checking on what, in some cases, is quite horribly complex calculations. (And I'm really hoping the "auto" type deduction extension gets added into the new standard to make our temporaries much easier to write!) phil -- change name before "@" to "phil" for email
Phil Richards wrote:
The point is we don't need anybody to take the strain because their isn't any. Unit conversion and/or unit enforcement just isn't done. Anywhere. At all. Ever.
We just want dimensionality checking on what, in some cases, is quite horribly complex calculations. (And I'm really hoping the "auto" type deduction extension gets added into the new standard to make our temporaries much easier to write!)
I want to refrain from participating in the discussion, since I have not worked on this as intensively as you and Andy. But perhaps it would be helpful for everyone, if you remind us what you are using your dimensions library for. Are you also doing physical dimensions (but always using the same units for each dimension) or is it something else? (For what it's worth, despite whatever opinions I have expressed in earlier discussions, I support the serious consideration and acceptance of ANY dimensions or units library, whether it meets my personal needs or not. It is long overdue. Unfortunately, people like me have contributed to the general paralysis. I hope that someone who has developed such a library would shrug off all the criticisms and just push ahead with submitting it, even if it does not meet everyone's needs. I am hopeful that once such a library is accepted into boost and used by more people, there will be more impetus towards ongoing improvements and enhancements towards a library more suited towards my own needs.)
On 2005-01-31, Deane Yang <deane_yang@yahoo.com> wrote:
I want to refrain from participating in the discussion, since I have not worked on this as intensively as you and Andy. But perhaps it would be helpful for everyone, if you remind us what you are using your dimensions library for. Are you also doing physical dimensions (but always using the same units for each dimension) or is it something else?
The former. All values stored with dimensionality specified are assumed to be in the relevant SI unit. We use the library as a safety check within simulation and modelling of real world scenarios. For various reasons, I can't say much more than that about what we do... We do use the library to represent *all* dimensioned variables, and accept the performance hit in compilation times. The benefits of checking easily outweigh the downsides. We've also had to address the absolute versus relative stuff, but that's a different discussion :-) phil -- change name before "@" to "phil" for email
"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ctm1jg$5q1$1@sea.gmane.org...
Phil Richards wrote:
The point is we don't need anybody to take the strain because their isn't any. Unit conversion and/or unit enforcement just isn't done. Anywhere. At all. Ever.
We just want dimensionality checking on what, in some cases, is quite horribly complex calculations. (And I'm really hoping the "auto" type deduction extension gets added into the new standard to make our temporaries much easier to write!)
I want to refrain from participating in the discussion, since I have not worked on this as intensively as you and Andy. But perhaps it would be helpful for everyone, if you remind us what you are using your dimensions library for.
Heres an example of pqs in use: http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/whats_next.html regards Andy Little
"Phil Richards" <news@derived-software.ltd.uk> wrote
On 2005-01-30, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
It's all we need because *all* our interfaces to the outside world are defined entirely in terms of SI units.
1)Unfortunately not every one has the luxury. Many incoherent units exist in many real world situations, where errors cost money and worse. 2)Even within SI a quantity can be expressed in various units. regards Andy Little
On 2005-01-31, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
1)Unfortunately not every one has the luxury. Many incoherent units exist in many real world situations, where errors cost money and worse.
Indeed. But, again, many people only need/want dimensional analysis. My/our project is one of them. We've only been doing it with a dimensional analysis setup for 3 years, so we've probably not found all the limits yet.
2)Even within SI a quantity can be expressed in various units.
But even then there is only one dimensionality. If all you are interested in is dimensionality, then everything is hunky dory. Really, it is that simple for many people. I accept that there are also probably many who want unit conversion and checking as well, but even they would probably like *something* rather than nothing. *shrug* Back to lurk mode. phil -- change name before "@" to "phil" for email
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050201182448.45525F53B@derisoft.derived-software.demon.co.uk...
On 2005-01-31, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
1)Unfortunately not every one has the luxury. Many incoherent units exist in many real world situations, where errors cost money and worse.
Indeed. But, again, many people only need/want dimensional analysis. My/our project is one of them. We've only been doing it with a dimensional analysis setup for 3 years, so we've probably not found all the limits yet.
2)Even within SI a quantity can be expressed in various units.
But even then there is only one dimensionality. If all you are interested in is dimensionality, then everything is hunky dory.
But you never are(OTOH maybe you are changing the impl from debug (quantity) to release((double) ) You are always interested in the value and the value must have units ( whether explicit and local or, remote and implied). I agree however that you might use an external convention and maybe this is an alternative to the very explicit units attached to a type used in the pqs UI. I guess you could select some particular unit for each of your your quantities making a set, and then apply some compiletime or possibly runtime scaling scaling factors to convert to somebody elses set. ( OTOH AFAICS the logical outcome is that you may end up with the system used in pqs.)
Really, it is that simple for many people. I accept that there are also probably many who want unit conversion and checking as well, but even they would probably like *something* rather than nothing.
Well if you dont want the range of units , simply select only the base units you want: namespace my{ typedef pqs::force::N force; typedef pqs::mass::kg mass; typedef pqs::acceleration::m_div_s2 acceleration; } using my::force; using my::mass; using my::acceleration; int main() { force f = mass(1) * acceleration(1); } regards Andy Little
My main motivation is to divide the idea of the units library from a large "thing" that requires much effort at consensus, and developement into two smaller "things" - one dependant upon the other. In now way do I want to suggest that units is not important. Its just something that should be separate and sit on top of a dimensional analisys library. This view is motivated by my personal view that the effort involved in all apects of software development grows disproportionatly to the size of the project involved. If the project can be divided into layers, or losely coupled components, the effort is reduced significantly. Also, it results in a better, more elegant, more widely applicable design. So lets make a minimalist dimensional analysis library whose function is to check arithmetic operations at compile time for consistency. I'm not even convinced that fractional dimensions are needed. If the really are, maybe the library can take a template paramter the specifies either an integer or compile time rational type. This would cleave off another tricky piece - compile time rationals. This would diminish the load on the writer of the dimensional analysis library and leave the issue of fractional dimensions to someone who needs this sufficiently to create a compile time rationals package. Robert Ramey Andy Little wrote:
"Phil Richards" <news@derived-software.ltd.uk> wrote
On 2005-01-30, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
It's all we need because *all* our interfaces to the outside world are defined entirely in terms of SI units.
1)Unfortunately not every one has the luxury. Many incoherent units exist in many real world situations, where errors cost money and worse. 2)Even within SI a quantity can be expressed in various units.
regards Andy Little
"Robert Ramey" <ramey@rrsd.com> wrote in message news:ctojd3$obh$1@sea.gmane.org...
So lets make a minimalist dimensional analysis library whose function is to check arithmetic operations at compile time for consistency.
I will attempt to write a Concept definition keeping as close as possible to David Abrahams example. ie with an interface based in mpl Of course there are some subtleties that will raise eyebrows, but there aint much I can do except explain the rationale. For instance I would treat a *raw* set of dimensional-exponents as having no particular name, because one set can represent more than one quantity. (e.g torque and energy both have the same set of dimensional-exponents). the Units library must inform the dimensional analysis library regarding this to try to forestall backward compatibility issues. FWIW I'd put this in boost::pqs // eg typedef boost::pqs::abstract_quantity< boost::mpl::vector<x,y,z>, // set of dimensional exponents boost::pqs::energy_tag, // to distinguish from torque , also anonymous_tag for results of operations
energy;
// Not typedef boost::mpl::vector<x,y,z> energy ; (This is basically using the semantics and interface of pqs but implementing in boost style: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/operations-semant... )
I'm not even convinced that fractional dimensions are needed.
It is possible they might occur in temporaries results of calculations in some cases. Its marginal but there are some eg opamp noise parameter that are specified as nanovolt per sqrt Hz.
If the really are, maybe the library can take a template paramter the specifies either an integer or compile time rational type.
AFAIK you may even be able to mix with boost::mpl::numeric_cast This would cleave off another tricky
piece - compile time rationals.
There are already several compile time rationals about (One I used is based on Matthias Schabels code).It should not be too hard to convert this to use the mpl style. This should enable Concept compatibility with whatever else might emerge as rational or fraction (e.g from Cromwell Enage). IOW A dimensional-exponent is a Concept essentially with an interface eg using mpl::plus etc. docs Might look like so: Concept DimensionalExponent // eg int_ , rational_c wish implements : mpl::plus<Dimensional ExponentL, Dimensional ExponentR> qa*qb mpl::minus<Dimensional ExponentL, Dimensional ExponentR> qa/qb mpl::multiplies<DimensionalExponent, Rational > pow<Rational>(q) mpl::equal<DimensionalExponentL,DimensionalExponentR> // dimensional analysis operator Concept DimensionalExponents // eg mpl::vector implements : mpl::plus<Dimensional ExponentsL, Dimensional ExponentsR> qa*qb mpl::minus<Dimensional ExponentsL, Dimensional ExponentsR> qa/qb mpl::multiplies<DimensionalExponents, Rational > pow<Rational>(q) mpl::equal<DimensionalExponentsL,DimensionalExponentsR> // dimensional analysis operator Concept AbstractQuantity // eg struct abstract_quantity implements : mpl::plus<AbstractQuantityL, AbstractQuantityR> qa*qb mpl::minus<AbstractQuantityL, AbstractQuantityR> qa/qb mpl::multiplies<AbstractQuantity, Rational > pow<Rational>(q) mpl::equal<AbstractQuantityL,AbstractQuantityR> // dimensional analysis operator negate, reciprocal also for convenience. regards Andy Little
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op. All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this. --Matt
This sounds good to me. Just one more enhancement, please. Given arithmetic types T1 and T2, dimension types X1 and X2, and an operator, then there are (user-defined) rules to determine result types T3 and X3 so that <T1, X1> op <T2,X2> returns a <T3,X3> A framework for doing this would be very useful to me. Matt Austern wrote:
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op.
All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this.
--Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Matt Austern writes:
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op.
That's basically what we have here at Meta. Low-profile, but extremely useful. FWIW, ours is spelled as 'scalar_type<T,X>'.
All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this.
Yep. -- Aleksey Gurtovoy MetaCommunications Engineering
"Matt Austern" <austern@gmail.com> wrote
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op.
I dont understand the tag part. (This must work seamlessly for inbuilt types too.) "for any T1 and T2" ... "rules to determine TR ( the result_type) in terms of T1, T2 and op". ..? I am not sure if this is exactly what you mean but I have tried to raise this on comp.std.c++: http://groups-beta.google.com/group/comp.std.c++/msg/a921d4d5bdb362e2 (note the above code inspired by Doug Gregors code in a boost discussion ) I think something like that would still be required for implementation even when decltype and auto are in place.
All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this.
As a detail, I think dimensions is orthogonal, eg mpl::plus<int_<A>,int_<B> >::type mpl::plus<int,int>::type The first is a compiletime operation, whereas the second is misuse of mpl::plus for result_type deduction. dimensional analysis occurs as the first, whereas we are discussing result_type deduction above. I Think ! regards Andy Little
At first I didn't understand this. But upon a little reflection I think it is a very interesting idea. If Dimensional analysis were built on top of this, odd ball cases such as "nanovolts per sqrt(Hz)" could be handled as specializations of <T,X1> op <T,X2> while default dimensional analysis would be used it implement the default cases. Robert Ramey Matt Austern wrote:
There's actually something even lower level than a dimension library. In essence, what we've got is: - We're generalizing the notion of an arithmetic type T to a type of the form <T,X>, where X is some sort of tag. - For any X1 and X2 and any arithmetic operation 'op', we have rules for whether <T,X1> op <T,X2> is well defined. If it is then the result is tagged as <T,X3>, and we have rules to determine X3 in terms of X1, X2, and op.
All of the knowledge about how to represent dimensional systems (mpl vectors, compile-time fractions, etc.) is higher level than this.
On Wed, 2 Feb 2005 12:48:06 -0800, Robert Ramey <ramey@rrsd.com> wrote:
At first I didn't understand this. But upon a little reflection I think it is a very interesting idea. If Dimensional analysis were built on top of this, odd ball cases such as "nanovolts per sqrt(Hz)" could be handled as specializations of <T,X1> op <T,X2> while default dimensional analysis would be used it implement the default cases.
What made me start thinking along these lines wasn't sophisticated cases, but really primitive ones. The very simplest rule for <T,X1> op <T,X2> is that it's illegal unless X1 and X2 are the same, and that's actually useful. It means that an int or double that you're using for one purpose can't accidentally be mixed up with one you're using for another purpose. You don't want to add apples and oranges, but you probably don't want to multiply them either. --Matt
Andy Little wrote:
I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
In my view, a dimension library has to exist independently of any units library. It is a separate and smaller concept. I should stand on its own. This will make it a) much easier and faster to come to consensus b) much easier develop and test. c) immediatly usefull. Lots of applications would find it useful even in the absense of a units library. d) not permit applications that use only this functionality to not be dependent on anything else. e) someday a units library will be built that uses this. Some people won't like it for on reason or another. If dimensions are a separate library - this won't be a problem as they can use their own version of units.
Still, as I said, agreement couldn't be achieved last time round on pretty much anything,
So lets try to agree on less - a dimensions library.
This seems to be a pessimistic view of what went on IMO. Is it not up to the librray designed to come up with a solution based on the discussions. I incorporated some things from these discussions into pqs. However I have always had a very specific view of what I want from a physical_quantities library, which has naturally had a major influence on the design.
Ahhhh - here is the rub. Is the library designers job to satisfy his "customers" or produce the most elegant, complete and useful package as he sees it. This is a very hard question. The main reason that boost libraries are of superior quality is that they come closest to reconciling these conflicting propositions. Libraries are develope by one or two people. This maintains a logical cohesiveness and elegance which is essential to a good library. On the other hand, they have to satisfy a large number of different "users". Fortunately, most users are focused on features though sometime implementation issues are important. So the appropriate attitude to be successful in this endeavor is a) Make a list of all the features it going to need to get accepted. b) Start making your library c) Realize that the job is too big to get done before its obsolete d) Divide your library in to smaller pieces that are useful in their own right e) Pick a piece f) go back to b This whole thing of trying to satify everyone and still keep the thing from becomming a microsoft-like API is a huge challange - actually much harder than writing and proving the code and manual (though that is way harder than it looks !!!!)
Though if there was to be a boost version, unfortunately this would need to be thrashed out. And that is the problem. It is a big project. I would ideally like to 'boostify' pqs but dont have time currently.
Basically, I believe that in software design, as in most other design edeavors, less is more.
However Robert Rameys idea to do the dimensional anlysis library alone seems good, as it is less contentious and surely would not be too much work.
"would not be too much work" - LOL so it would seem. add in the documentation, tests, bjam hassle, varying compilers (add in a lot for this). even this is going to be a lot of work If this could be done a) we would have something useful b) people would have something to use for experiments on units. Issues of money, etc could be experimented with independently. This would be very helpful in a future discussion of units as we would have more real data and wouldn't have to rely so much on speculation. c) it has a better chance of getting accepted. d) This would add a lot to the writers resume - thereby making it easier justify the time invested - which is still going to be alot. Perhaps this could be used to flog the development of a rationals library. Another thing we sorely need. Robert Ramey
From: "Robert Ramey" <ramey@rrsd.com>
Andy Little wrote:
I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
In my view, a dimension library has to exist independently of any units library. It is a separate and smaller concept. I should stand on its own.
At the risk of sounding stupid: What's a dimension library? I.e. how might it look like, and be used (preferably a code example)? I've searched the Boost list for "dimension library"/"dimensions library", but your posting is the only one coming up. For example, if it only takes care of dimensional analysis (i.e. dimension calculations), how many dimensions should it have, if it's independent of units? If the answer is "user-configurable through typelists/vectors", have anyone done any compile-time timing of dimension calulation-heavy code using this approach, compared to a fixed set of dimensions? Won't this bring us right back to the "how many dimensions"-discussion of a unit/quantity library? Regards, Terje
Terje Slettebø wrote:
What's a dimension library? I.e. how might it look like, and be used (preferably a code example)? I've searched the Boost list for "dimension library"/"dimensions library", but your posting is the only one coming up.
This whole thread was started by question about ...\libs\mpl\doc\tutorial\dimensional-analysis.html which uses dimensional analysis as an example of a possible application of mpl. In my view, this tutorial is makes a great case for the utility of such a library and explanation of how it might be implemented
For example, if it only takes care of dimensional analysis (i.e. dimension calculations), how many dimensions should it have, if it's independent of units? If the answer is "user-configurable through typelists/vectors", have anyone done any compile-time timing of dimension calulation-heavy code using this approach, compared to a fixed set of dimensions?
I would expect that number of dimensions would be fixed a compile time. Compile time will be noticebly slower for program modules that use such a library. For applications where this presents a problem, a dimenstions library along the lines discussed above wouldn't be helpful.
Won't this bring us right back to the "how many dimensions"-discussion of a unit/quantity library?
if it were user configurable, I wouldn't think so. I would expect that such a library would have a base implementation along with a higher layer specifying a common set of dimensions. Anyone not happy the the chosen set, he could just use the base layer and use his own set of dimensions. After all, the base algorithms don't depend on what the dimensions mean. Robert Ramey
From: "Robert Ramey" <ramey@rrsd.com>
Terje Slettebø wrote:
What's a dimension library? I.e. how might it look like, and be used (preferably a code example)? I've searched the Boost list for "dimension library"/"dimensions library", but your posting is the only one coming up.
This whole thread was started by question about ...\libs\mpl\doc\tutorial\dimensional-analysis.html which uses dimensional analysis as an example of a possible application of mpl. In my view, this tutorial is makes a great case for the utility of such a library and explanation of how it might be implemented
Agreed. A couple of years ago, I played with a dimensional analysis/quantity library, myself, using Loki's typelists to store the dimensions. However, the combination of them were rather involved, and not something like the elegant solution of using mpl::transform (which didn't exist at the time, at least not as a Boost library). It was just the terminology, "dimension library", that I wondered about, and I guessed it was about the dimensions, without attaching any particular meaning to them (which was the case). It has been said in this thread that this could sidestep some of the issues of a unit library, but there still seems to be a number of them for a dimensional analysis library, such as the number of dimensions, and whether they should be fractional or not. As has been noted, a number of dimension/quantity libraries have been developed and proposed over the years, and I guess one useful test of a dimension library would be if it's possible to write a useful quantity library for it (or more). As Andy and others who have been involved in these discussions are all too aware of, there are many tricky issues involved in making a quantity library (such as his PQS library), such as "kg" being the only SI base unit with a prefix, and if you have 1000 * 1 kg, you won't get 1 k(kg), but 1 Mg; the different temperature scales, and perhaps even support for non-SI units, like feet, mile, etc. As well as how to present these quantities, internationalisation, and so on.
For example, if it only takes care of dimensional analysis (i.e. dimension calculations), how many dimensions should it have, if it's independent of units? If the answer is "user-configurable through typelists/vectors", have anyone done any compile-time timing of dimension calulation-heavy code using this approach, compared to a fixed set of dimensions?
I would expect that number of dimensions would be fixed a compile time.
Then it also depends on how that is done. I'm not saying there's a problem; I haven't measured, but I think it should be a consideration. I would think that a simple class template with N integral parameters (or rationals, somehow), where they are combined to form new types using simple +, -, * and /, could be a heck of a lot faster at compile time, than one using mpl::vector, and mpl::transform, and then again I may be wrong, and also the difference may not be enough to be a problem.
Won't this bring us right back to the "how many dimensions"-discussion of a unit/quantity library?
if it were user configurable, I wouldn't think so. I would expect that such a library would have a base implementation along with a higher layer specifying a common set of dimensions. Anyone not happy the the chosen set, he could just use the base layer and use his own set of dimensions.
I wonder what that base functionality would be, when it won't know about the number of dimensions, and it won't know their meaning. It seems a little like "stone soup", :) but I'm willing to be convinced. ("Ok, so we can hardly agree on anything in this library, so let's not make _anything_. Can we agree on that? Yes!") :) Regards, Terje
participants (1)
-
Aleksey Gurtovoy -
Andy Little -
David Abrahams -
Deane Yang -
Matt Austern -
Phil Richards -
Robert Ramey -
Sérgio Vale e Pace -
Terje Slettebø