"Dave Steffen" <dgsteffen@numerica.us> wrote in message news:17644.39259.602176.507250@yttrium.numerica.us...

Greer, Joe writes: [...]

...

Also, make sure that you are solving problems that are really likely to occur. It is nice to be as absolutely type safe as possible, but often that gets in the way of getting real work done as well. Just a thought.

Ya know, that's a very good point, and it puts a name to that little nagging thing that's been bugging me during this whole discussion.

What, exactly, are this library's use cases?

All kinds of people want all kinds of things. It seems to me that most of the discussion about these libraries - both the current one and the-library-recently-renamed Quan - are circular swirls of "I'd like it to do this" and "but then what about that".

This is merely because the use cases are potentially pretty wide. In the review I made it clear that I was limiting the scope of Quan to the SI unit system, because that is the one I understand. If I resubmitted the library it could be rejected as not being generic enough and there are inklings from this thread that this may be the reaction. But I don't have the time or the knowledge to write a truly generic physical quantities library and if that is the requirement then there isnt much point in resubmitting Quan for another review AFAICS.

I think this is because there is not clearly stated purpose to "Unit Library". What, exactly, is it used for? What code can you not write that you could write with the Units Library/Quan? What errors can you make now that you can't make with Units Library/Quan?

Maybe these questions have been answered, and I didn't notice 'em going past; but based on these discussions, I'm inclined to think that in general, no two people agree on exactly _why_ these libraries are useful.

You can read about the rationale behind Quan in the docs: http://tinyurl.com/fowwc regards Andy Little

"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:2F9215A5-A36E-4139-A289-E0E6C095AEC5@itp.phys.ethz.ch...

On Aug 23, 2006, at 8:50 PM, Andy Little wrote:

...

This is merely because the use cases are potentially pretty wide. In the review I made it clear that I was limiting the scope of Quan to the SI unit system, because that is the one I understand. If I resubmitted the library it could be rejected as not being generic enough and there are inklings from this thread that this may be the reaction. But I don't have the time or the knowledge to write a truly generic physical quantities library and if that is the requirement then there isnt much point in resubmitting Quan for another review AFAICS.

Can the dimension checking part of the library be used without the SI unit system? For most other unit systems I use, I mainly need dimension checking and not conversions between different units, such as km or m? Thus just a quantity with dimensions would be useful to catch programming errors.

Yes. In the signature fixed_quantity<Unit, ValueType>, the Unit parameter can be so modelled that it only allows base units to be used, and in this case there is no conversion overhead BTW, a multiply is simply a multiply of the numeric values for example). By default Quan wont work across Unit models (IOW the class template names of units must match), which means that attempting to do calculations between Units with different class template names will fail at compile time. By this means you can guarantee that you can prevent any conversions. (FWIW there is also the option to allow unit conversions but make them explicit, prompted by Deane Yang easrlier in this thread.) As yet this only applies easily to the CVS version of Quan, but I hope that we will be able to get another release out shortly, which reflects what is currently in the CVS version. I will hopefully announce it boost.devel once the next release is available. regards Andy Little

"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ecpndi$2mb$1@sea.gmane.org...

Andy Little wrote:

...

...

Can the dimension checking part of the library be used without the SI unit system? For most other unit systems I use, I mainly need dimension checking and not conversions between different units, such as km or m? Thus just a quantity with dimensions would be useful to catch programming errors.

Yes. In the signature fixed_quantity<Unit, ValueType>, the Unit parameter can be so modelled that it only allows base units to be used, and in this case there is no conversion overhead BTW, a multiply is simply a multiply of the numeric values for example). By default Quan wont work across Unit models (IOW the class template names of units must match), which means that attempting to do calculations between Units with different class template names will fail at compile time. By this means you can guarantee that you can prevent any conversions. (FWIW there is also the option to allow unit conversions but make them explicit, prompted by Deane Yang easrlier in this thread.)

I guess I wasn't particularly clear earlier in this thread, because fixed_quantity appears to be what I want. I'm sorry for not RTFM (I did try to read the documentation once, but my memory is not what it used to be), but I have two quick questions:

1) Does operator*(fixed_quantity<Unit1, ValueType1> x, fixed_quantity<Unit2, ValueType2> y) work and, if so, what is the result type, assuming that operator*(ValueType1 v, ValueType2 w) returns a ValueType3?

OK. The following relates to the CVS version currently on the two_param-branch, but much applies to previous versions of Quan/PQS. Dealing with the ValueTypes first, the result type of ValueType1 * ValueType2 is encoded in the compile time expression: binary_operation<ValueType1,times, ValueType2>::type. The implementation provides a specialisation for inbuilt types, and this follows the promotion/conversion rules on the respective calc in the C++ standard. We have also been recently testing with boost::numeric::interval and (with the appropriate specialisations) this seems to be working now and I believe that other numeric UDT ValueTypes will now work OK. The dimension of the result is found by adding the respective dimensions of the operands. If the result is dimensioned, then in case of conforming SI quantities the exponent of the conversion factor of the result is found by adding the exponents in the conversion factors of the operands. For example a pressure of 1 megapascale ( MPa) has a conversion-factor exponent of (10 to power) 6. An area in square millimeters has a conversion-factor exponent of (10 to power) -6. The type resulting from multiplication of area::mm2 * pressure::MPa is an anonymous type dimensionally equivalent to force, and has a conversion factor exponent of 0, hence could be assigned directly to a force in Newtons, without requiring a unit conversion. Note also that (if you work through the maths) you will see that any dimensioned multiplication (and division too FWIW) of 2 SI quantities is, at runtime, just a direct multiplication of their numeric values. There is no unit conversion or runtime scaling involved. The only time that a scaling may occur is when the temporary result of the expression is assigned to an L_value in a different unit, and this situation can now be detected, due to your suggestion to make conversions explicit and it works rather nicely. IOW if you use SI quantities then calculations in Quan can be as efficient as those calculated manually. Also quantities with very large and small exponents can be used as efficiently as base unit quantities. The above may sound complicated, but if you think of how you would do the calculation manually, then it should become clear what is going on. If the result is dimensionless, then the result is a numeric, whose type is the result type of multiplying the ValueTypes of the operands, as above( which must obviously be multipliable else there will be a compile error). In this case the calc first proceeds as for the dimensioned result case , but then the result numeric value is divided by 10 to power of the exponent of the conversion factor of the result (if the exponent is non zero), to give a pure number. For non SI units it is as if the values were converted to the nearest SI units before doing the multiplication and then the calculation proceeds as for the SI unit case (In fact the latest version of Quan does a fair amount of optimisation of all these calcs behind the scenes to try to remove any redundant calculations and hence increase accuracy and calculation speed)

2) Can you raise a fixed_quantity to a rational power (I personally only need the power 1/2)?

Yes. here is an example. Note that because raising to a power affects the type of the result, a special version of pow is required: #include <quan/out/force.hpp> int main() { quan::force::N f(100); std::cout << quan::pow<1,2>(f) <<'\n'; } output: 10 kg+1/2.m+1/2.s-1 regards Andy Little

"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ecr5ti$bls$1@sea.gmane.org...

Andy Little wrote:

...

"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ecpndi$2mb$1@sea.gmane.org...

...

Dealing with the ValueTypes first, the result type of ValueType1 * ValueType2 is encoded in the compile time expression: binary_operation<ValueType1,times, ValueType2>::type. The implementation provides a specialisation for inbuilt types, and this follows the promotion/conversion rules on the respective calc in the C++ standard. We have also been recently testing with boost::numeric::interval and (with the appropriate specialisations) this seems to be working now and I believe that other numeric UDT ValueTypes will now work OK.

Does this mean that if ValueType1, ValueType2, and ValueType3 are UDT's and I do something like:

template <> struct binary_operation<ValueType1,ValueType2> { typedef ValueType3 type; };

then everything will work properly?

Yes. though there are versions of binary_operation for +,-, *,/ and pow . and there are a couple of other requirements. One is (only if you use non SI units) that the UDT can be multiplied by an inbuilt type. The other is that you need to tell Quan that your UDT is intended to be a numeric type by specialising quan::meta::is_numeric for it, to return true. Also each UDT seems to have its own peculiarities. For example boost::numeric::interval can only be raised to an integer power, AFAICS, so it is quite difficult to come up with a generic quan::pow<N,D>(udt, ??) function and I think it will be necessry to create an overload in the quan namespace per udt, which checks any requirements and forwards to the relevant udt's function. Here is the quan::pow function that seems to work OK for boost::numeric::interval: template <int32 N,int32 D,typename T> inline typename quan::meta::binary_operation< boost::numeric::interval<T>,quan::meta::pow,quan::meta::rational<N,D> >::type pow ( boost::numeric::interval<T> const & v) { BOOST_STATIC_ASSERT(D == 1); typedef typename quan::meta::binary_operation< boost::numeric::interval<T>,quan::meta::pow,quan::meta::rational<N,D> >::type result_type; result_type result = boost::numeric::pow(v,N); } Bear in mind that I am talking about the latest CVS version on two_param Branch ins the Quan Sourceforge CVS, where I spent some time on getting UDT's working last week. Anyway I am fairly sure that in general UDT's can be made to work with Quan, but not totally effortlessly unfortunately.

...

The dimension of the result is found by adding the respective dimensions of the operands. ... <snip>

Oops. I guess fixed_quantity has to have one of the physical dimensions represented in SI units, eh? Never mind.

No. Firstly the Concept of unit is separate from the Concept of dimension. A quantity within a particular unit system can have various units but be dimensionally equivalent. Secondly, fundamentally the dimension of the quantity is represented as a series of numbers, ideally rationals but in limited cases you can get integers to work (just no division). Those numbers can be taken to mean anything in any unit system you want. The StaticUnit doesnt expose the dimension directly so you can have dimension represented any way you want, with any number of elements. You can see an example using a mpl::vector here: http://tinyurl.com/kbvbq The implementation of the quan::Static Unit concept for the above is here, note again the use of binary_operation, which is overloaded for many purposes http://tinyurl.com/k3ofd There is also a refinement of Static Unit namely Static SI Unit. It is only at the Static SI unit level that the dimension is assumed to be made up of the 7 base SI quantities. The particular unit system for a Static Unit can be queried by get_unit_system<StaticUnit>::type. If the unit system is the SI unit system then the implementation assumes that the Static Unit is in fact a Static SI Unit too, a bit like dynamic_cast for a down cast maybe. OTOH it should be realised that I have only provided a fleshed out implementation for the SI unit system and that checking for other unit systems is quite new and not yet fully realised, however the potential is there, though it probably needs an implemenattion or two to see whether it will work in practise. regards Andy Little

Andy Little writes: [...]

The serious point was that there is a relation between torque and energy, but they are distinct. and actually the relation is slightly more complicated than I stated, but I think that for a bolt of N turns and assuming a constant torque, the heat dissipated (in Joules) == applied_torque (in N.m) * N / (2 * pi).

OK, hold on here. Work = change in energy = force * distance. (Actually, the integral of force * infinetesimal displacement, but let's assume constant forces here.) Torque = radius * Force. (Actually, it's a cross product, but let's assume the force is always perpendicular to the lever arm.) Therefore, for a given torque, Force = Torque / radius. So, the work done (delta engergy) in applying a constant torque to your bolt is W = Force * distance = ( Torque * distance ) / radius. Now, if you turn the bolt N times, the distance you've moved the end of your lever arm (where you're applying the force) is distance = 2 * pi * radius * N. Plugging this in, W = (Torque * 2 * pi * radius * N) / radius or W = 2 * pi * N * Torque. [[ End of physics lesson ]] ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation - Douglas Hofstadter dgsteffen at numerica dot us