pqs_3_0_2 available in the Boost.Vault
pqs_3_0_2, the next version of physical_quantities library proposal for boost, is available in the vault in Physical Quantities Units directory. This version has much improved compilation speed typically (say) 4 seconds as opposed to 30 for pqs_3_0_1. (pqs_3_0_1 is still available for comparison purposes). Little or no documentation as yet, but useage is relatively straightforward as I hope can be gleaned from files in the libs/pqs/examples and libs/tpqs/test directories. I hope to get down to writing proper documentation for the library next. regards Andy Little
Errata in Pqs_3_0_2 : units for predefined socalled 'incoherent' quantities used a rational with denominator of 10000000 rather than 1000000, so calculations betwen coherent and incoherent quantities in this version will be out by factor of 10. Fixed in pqs_3_0_3 now in the vault. regards Andy Little
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
Fixed in pqs_3_0_3 now in the vault.
I think this library is extremely useful. The only thing I don't like (on first pass) is the use of the default_value_type thus: struct length : length_<quantity_traits::default_value_type>{}; I'd prefer to explicity specify the type every time I used it so: length<int>::m Then perhaps pqs could extend its remit to include checking for loss of precision as well as dimensional analysis.
"Simon Carter" wrote
I think this library is extremely useful.
Great. The only thing I don't like (on first
pass) is the use of the default_value_type thus:
struct length : length_<quantity_traits::default_value_type>{};
I'd prefer to explicity specify the type every time I used it so:
length<int>::m
This option is of course available by adding the '_' suffix to the quantity name: length_<float>::m; length_<long double>::m; I am not blown away by this useage of the trailing underscore on the quantity name as I am aware that it is popular to use the trailing underscore for member data, but I cant think of anything better. Suggestion welcomed. The useage : length::m is simply a convenience. BTW The default_value_type is usually set to a double but can be changed to eg float by (slightly obscurely I now observe) changing the BOOST_PQS_REAL_TYPE defined in <boost/pqs/config.hpp> An alternative to the above scheme would be to provide a namespace for one or each type : boost::pqs::implicit_param::length::m; boost::pqs::explicit_param::length<int>::m; with the idea to use a using declaration to select one of them : using boost::implicit_param::length; This approach has seemed messy to me., but I am open to ideas.
Then perhaps pqs could extend its remit to include checking for loss of precision as well as dimensional analysis.
Older preboost versions of pqs used boost::numeric::converter which threw an exception (subject to a policy) when an out of range conversion occurred eg when say a runtime double value_type has a value too big for an int. It got lost in all my changes. I shall put that back in to the system next version Is that the type of thing you mean or do you mean something else such as keeping track of the precision ? Glad you broadly like the library ! regards Andy Little
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
This option is of course available by adding the '_' suffix to the quantity name:
length_<float>::m; length_<long double>::m;
I am not blown away by this useage of the trailing underscore on the quantity name as I am aware that it is popular to use the trailing underscore for member data, but I cant think of anything better. Suggestion welcomed.
I think I would prefer to always explictly specify the underlying type and do away with the defaults, but perhaps I'm odd.
Then perhaps pqs could extend its remit to include checking for loss of precision as well as dimensional analysis.
Older preboost versions of pqs used boost::numeric::converter which threw an exception (subject to a policy) when an out of range conversion occurred eg when say a runtime double value_type has a value too big for an int. It got lost in all my changes. I shall put that back in to the system next version
Is that the type of thing you mean or do you mean something else such as keeping track of the precision ?
I did mean exactly this - out of range conversions - but it would be much nicer to see a compile-time failure when it is possible that a value can be too big rather than an exception when the conversion actually fails. Simon
"Simon Carter" <simon.carter@ttplabtech.com> wrote in message news:loom.20060123T172320-254@post.gmane.org...
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
This option is of course available by adding the '_' suffix to the quantity name:
length_<float>::m; length_<long double>::m;
I am not blown away by this useage of the trailing underscore on the quantity name as I am aware that it is popular to use the trailing underscore for member data, but I cant think of anything better. Suggestion welcomed.
I think I would prefer to always explictly specify the underlying type and do away with the defaults, but perhaps I'm odd.
OK I will have to set up a FAQ in the documentation regarding that subject. There are problems with the current scheme its true. My feeling ( and the reason I used this scheme) is that the vast majority of use cases use the default ( double) value_type for a quantity and that the current scheme aids legibility. You do suffer if you dont want to use it though. Changing the default (eg. to a float) is possible in the <pqs/config.hpp> or <pqs/quantity_traits.hpp> files. I could suggest the default mechanism to the user as a way around having to type out the double parameter rather than forcing it on them I guess.
Then perhaps pqs could extend its remit to include checking for loss of precision as well as dimensional analysis.
Older preboost versions of pqs used boost::numeric::converter which threw an exception (subject to a policy) when an out of range conversion occurred eg when say a runtime double value_type has a value too big for an int. It got lost in all my changes. I shall put that back in to the system next version
Is that the type of thing you mean or do you mean something else such as keeping track of the precision ?
I did mean exactly this - out of range conversions - but it would be much nicer to see a compile-time failure when it is possible that a value can be too big rather than an exception when the conversion actually fails.
You mean disallowing (say) double to int conversons and so on? I am pretty sure that would be possible via a policy in Boost.Numeric Converter. It is possible to modify this too. Its currently at line 93 in <pqs/quantity_traits.hpp>. I will have to raise that as question in the documentation too. As it stands I have used the default converter action but using round-nearest rounding scheme. BTW conversion isnt working properly in pqs_3_0_4 . I am converting too early for Boost.Numeric Converter to do its job. Todo for next version. regards Andy Little
"Andy Little" wrote
Fixed in pqs_3_0_3 now in the vault.
Found another bug in the data comprising the predefined quantities. There are probably others too,so have opted to add an erratta list with fixes, (next to pqs_3_0_3 zip file in the vault ) for the moment rather than creating myriad versions to download. As well as documentation, I'll put a lot more tests for the next version too! regards Andy Little
participants (2)
-
Andy Little -
Simon Carter