[math] common_factor template parameters
Hi, static_gcc and static_lcm have unsigned long parameters. template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd; Could these be changed to uintmax_t? Is there any deep reason to don't define them for singed integers (intmax_t) also? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
static_gcc and static_lcm have unsigned long parameters.
template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd;
Could these be changed to uintmax_t?
I would think so yes.
Is there any deep reason to don't define them for singed integers (intmax_t) also?
No, since the result for both functions is always taken as positive for one or more negative arguments. However.... unless we change the interface, it's hard to see how to accomplish this easily? Particularly as the unsigned version has a greater range? Note that if the arguments might be negative then you could just write: static_lcm<(arg1 < 0 ? -arg1 : arg1), (arg2 < 0 ? -arg2 : arg2)>::value to achieve the same effect. HTH, John.
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Saturday, June 26, 2010 6:22 PM Subject: Re: [boost] [math] common_factor template parameters
static_gcc and static_lcm have unsigned long parameters.
template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd;
Could these be changed to uintmax_t?
I would think so yes.
Do you need I make a ticket?
Is there any deep reason to don't define them for singed integers (intmax_t) also?
No, since the result for both functions is always taken as positive for one or more negative arguments. However.... unless we change the interface, it's hard to see how to accomplish this easily? Particularly as the unsigned version has a greater range?
Note that if the arguments might be negative then you could just write:
static_lcm<(arg1 < 0 ? -arg1 : arg1), (arg2 < 0 ? -arg2 : arg2)>::value
to achieve the same effect.
Ok, I will use it in this way. Joel Falcou suggested on another thread to define MPL integral constant metafunction for static_abs and static_sign. namespace XXX { template <typename ICT> abs : mpl::if_<is_unsigned<ICT::value_type>, ICT, mpl::integral_c<make_unsigned<ICT::value_type>, (ICT::value < 0 ? -ICT::value : ICT::value) > > {}; } Murillo, a GSOC student, is working on some metafunctions for integers including between others abs and sign. What do you think about a MPL integral constant metafunction having as parameters integral constant types on top of static_lcm? namespace XXX { template <typename ICT1, typename ICT2> lcm : mpl::integral_c<uintmax_t, static_lcm< XXX::abs<ICT1>::value, XXX::abs<ICT1>::value > > {}; } Should these metafunctions be added to the 'mpl' namespace? if not what could be the a good name for XXX? Best, Vicente
static_gcc and static_lcm have unsigned long parameters.
template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd;
Could these be changed to uintmax_t?
I would think so yes.
Do you need I make a ticket?
Well... it might prevent me from forgetting! ;-)
Murillo, a GSOC student, is working on some metafunctions for integers including between others abs and sign. What do you think about a MPL integral constant metafunction having as parameters integral constant types on top of static_lcm?
namespace XXX {
template <typename ICT1, typename ICT2> lcm : mpl::integral_c<uintmax_t, static_lcm< XXX::abs<ICT1>::value, XXX::abs<ICT1>::value > > {}; }
Should these metafunctions be added to the 'mpl' namespace? if not what could be the a good name for XXX?
No idea, but they look like mpl metafunctions. I guess if the mpl guys don't want them then Boost.Math could host them, it's really a question of where users are mostly likely to go looking for them. I'm not sure what the answer to is though... John.
John Maddock <boost.regex <at> virgin.net> writes:
No idea, but they look like mpl metafunctions. I guess if the mpl guys don't want them then Boost.Math could host them, it's really a question of where users are mostly likely to go looking for them. I'm not sure what the answer to is though...
I'd say they absolutely belong in Boost.Math or Boost.Integer rather than Boost.MPL. Whether something is a compile-time facility or a run-time facility should not determine what library it goes in; I'd wager most compile-time facilities in boost are implemented in terms of MPL. The domain of MPL is compile-time type sequences and algorithms on those sequences; the domain of the code in question seems to me to be more strongly related to Boost.Integer's static_log2 and static_min_max than anything else.
Adam Merz wrote:
I'd say they absolutely belong in Boost.Math or Boost.Integer rather than Boost.MPL. Whether something is a compile-time facility or a run-time facility should not determine what library it goes in; I'd wager most compile-time facilities in boost are implemented in terms of MPL. The domain of MPL is compile-time type sequences and algorithms on those sequences; the domain of the code in question seems to me to be more strongly related to Boost.Integer's static_log2 and static_min_max than anything else My initial suggestion was not to move them to MPL but to make them conformant to MPL Integral Constant concept so they can be freely used in cunjunction with other numeric related meta-function form MPL.
I'd say they absolutely belong in Boost.Math or Boost.Integer rather than Boost.MPL. Whether something is a compile-time facility or a run-time facility should not determine what library it goes in; I'd wager most compile-time facilities in boost are implemented in terms of MPL. The domain of MPL is compile-time type sequences and algorithms on those sequences; the domain of the code in question seems to me to be more strongly related to Boost.Integer's static_log2 and static_min_max than anything else
My initial suggestion was not to move them to MPL but to make them conformant to MPL Integral Constant concept so they can be freely used in cunjunction with other numeric related meta-function form MPL.
That should happen too - but the suggestion was for traits that accept types rather than values as arguments - what mpl::if_ is to mpl::if_c. John.
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Monday, June 28, 2010 5:59 PM Subject: Re: [boost] [math] common_factor template parameters
static_gcc and static_lcm have unsigned long parameters.
template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd;
Could these be changed to uintmax_t?
This is now fixed in Trunk.
Thanks, Vicente
participants (4)
-
Adam Merz -
joel falcou -
John Maddock -
vicente.botet