Re: [boost] [mpl::math Rational] type member

From: Cromwell Enage (sponage_at_[hidden])
Date: 2005-10-24 20:20:58

--- 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.

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.

> Overall though I am opposed to it because I believe
> the current interface is superior from a user's
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