--- Andy Little wrote:
If you're trying to save cycles at compilation time by normalizing lazily, then of course the numerator and denominator typedefs can't be normalized. So, sure, typedefs for the template arguments sound fine to me.
I wouldnt mind this from a practical point of view. I believe that Cromwell's implementation of gcd is overkill for my needs, so I guess that would make it easier to customise.
Overall though I am opposed to it because I believe the current interface is superior from a user's
Well, the "generic" implementation is overkill because it can't make too many assumptions about the input metatype. For integral constants, you can specialize gcd_impl and substitute your own implementation (e.g. binary GCD). For big_integral, I've found that following Peder's approach--favoring BOOST_STATIC_CONSTANT expressions over typedefs whenever possible--drastically cuts down compile times at a cost of slightly reduced portability, which is not a great concern right now. Perhaps a similar approach to gcd_impl will also serve you well. point
of view and it's a classic case of optimisation ruling the interface.
In the case of dimensional analysis in a quantity, it seems to be perfectly possible to mix rationals and integral constants in an mpl container, though some care needs to be taken with the maths. (It may be worth using a custom division operator). In use for dimensional analysis rationals are actually pretty rare (integral constants can be substituted in the vast majority of cases) and all rationals used have a very small range of values, so I hope that any poor compile time performance of rationals will not have such a great effect. In fact I think that division is the only operation where extra care is required, though any operation involving a rational requires normalisation if it's involved in math and comparisons etc.
I guess it might be worth getting Cromwell Enage's view as to whether he feels changing the current interface is worthwhile.
One of the capabilities I tried to build into the library was the ability for advanced numeric metafunctions to treat rationals, mixed_numbers, and now doubles as generically as possible. To this end, I provided the is_negative, numerator, denominator, whole_part, and rational_part numeric metafunctions, each with a corresponding _impl metafunction class. Any real numeric metatype on which these metafunctions (and, of course, the arithmetic and comparison metafunctions) can operate is considered to be implementing the "current interface". (In order to get intelligible output, one must also specialize the runtime_value_impl metafunction class for the metatype, and/or override the << operator for output streams.) For my part, I'll provide the following macros in the next version: BOOST_MPL_MATH_NUMERATOR_OF_MIXED_NUMBER(tag) BOOST_MPL_MATH_DENOMINATOR_OF_MIXED_NUMBER(tag) BOOST_MPL_MATH_WHOLE_PART_OF_RATIONAL(tag) BOOST_MPL_MATH_RATIONAL_PART_OF_RATIONAL(tag) For example, Peder Holt's double requires specializations of is_negative_impl, whole_part, and rational_part, as well as the arithmetic and comparison operators. Once they are provided, we can add the following two statements: BOOST_MPL_MATH_NUMERATOR_OF_MIXED_NUMBER(double_tag) BOOST_MPL_MATH_DENOMINATOR_OF_MIXED_NUMBER(double_tag) Voila! Peder Holt's double is now a Real Numeric Constant. For the problem space you describe, you can start by changing rational_c to your liking, as the numerator and denominator are guaranteed to be primitive integral constants. Once you do so, you'll have to provide a corresponding rational_c_tag that inherits from prior<rational_tag>::type, a BOOST_MPL_AUX_NUMERIC_CAST specialization from rational_c to rational, and specializations of is_negative_impl, numerator_impl, and denominator_impl. (And don't forget runtime_value_impl and <<.) Then you can finish it off with: BOOST_MPL_MATH_WHOLE_PART_OF_RATIONAL(rational_c_tag) BOOST_MPL_MATH_RATIONAL_PART_OF_RATIONAL(rational_c_tag) HTH! Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com