punits][accumulators] buggy behavior for min accumulator of quantities
Hi, Sometimes it is difficult to make boost::units quantities with other libraries. For example to have boost::accumulators mean work with units, one has to specialize division by integer for quantities. In this example the accumulators and units compiles out of the box but gives an incorrect answer. #include<boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics/min.hpp> // or other stat features #include <boost/accumulators/statistics/max.hpp> // or other stat features #include<boost/units/systems/si.hpp> #include<boost/units/io.hpp> using namespace boost::accumulators; using namespace boost::units; int main(){ accumulator_set<quantity<si::time>, features<tag::min, tag::max> > a; a(2.1*si::second); a(2.0*si::second); a(4.1*si::second); std::cout << extract::min(a)<< " " << extract::max(a)<< std::endl ; return 0; } It prints: 0 s 4.1 s instead of: 2.1 s 4.1 s So, it seems that the min extractor fails for quantities. I would like to know if there is a way to correctly specialize "min" for quantities. (By the way, std::min for quantities works fine). However the behavior is unfortunate in the first place. Regardless of the solution I would label this as a bug of one of the two libraries. Thank you, Alfredo
Answering to myself: On Mar 12, 3:04 pm, alfC <alfredo.cor...@gmail.com> wrote:
Hi, Sometimes it is difficult to make boost::units quantities with other libraries. For example to have boost::accumulators mean work with units, one has to specialize division by integer for quantities.
In this example the accumulators and units compiles out of the box but gives an incorrect answer.
I found the solution, just add #include<boost/units/limits.hpp> in this way the min/max function can initialize the default maximum/ minimum value, which is given by the numeric limits of the type. Anyway, I would suggest to the authors of boost.units to include limits.hpp by default in the core library in order *to avoid this surprises*. Or better yet, make the author of boost.accumulators to support boost.units. By the way I made boost accumulators to work with min, max (see above) and mean by adding the below code. Variance, etc. is more difficult to implement because boost.accumulators assumes that t*t is always of type t. namespace boost {namespace numeric{namespace functional{ using namespace boost::units; template<class Unit, typename Y> struct quantity_tag{}; template<class Unit, typename Y> struct tag<quantity<Unit,Y> >{ typedef quantity_tag<Unit,Y> type; }; template<typename Left, typename Right> struct average<Left, Right, quantity_tag<typename Left::unit_type, typename Left::value_type>, void>{ typedef Left result_type; result_type operator()(Left & left, Right & right) const{ return left/(typename Left::value_type)right; } }; }}} Thanks, Alfredo
On 3/13/2011 7:45 AM, alfC wrote:
Anyway, I would suggest to the authors of boost.units to include limits.hpp by default in the core library in order *to avoid this surprises*. Or better yet, make the author of boost.accumulators to support boost.units. <snip>
This is a known shortcoming of Boost.Accumulators. Things get complicated when t*t has a different type than t and such. Sprinkling BOOST_DECLTYPE (or decltype where it's supported) would solve the issue, but finding all such assumptions everywhere would be hard. Appropriate use of a degenerate numeric archetype in all the tests would do it, but adding that and then adding decltype everywhere would be a big job. But you should file a bug, anyway. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric,
This is a known shortcoming of Boost.Accumulators. Things get complicated when t*t has a different type than t and such. Sprinkling BOOST_DECLTYPE (or decltype where it's supported) would solve the issue, but finding all such assumptions everywhere would be hard. Appropriate use of a degenerate numeric archetype in all the tests would do it, but adding that and then adding decltype everywhere would be a big job. But you should file a bug, anyway.
Thanks, bug submited. https://svn.boost.org/trac/boost/ticket/5302 (I forgot to use the wiki code formatting, sorry)
Thanks,
-- Eric Niebler BoostPro Computinghttp://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-us...@lists.boost.orghttp://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
alfC -
Eric Niebler