
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20051031 15:48:43
 Andy Little wrote:
> Shouldn't the two parts be described as integer_part
> and fractional_part?
IMHO integer_part is not as descriptive as whole_part.
> And also ... Why do they need to be macros?
The default implementations of whole_part and
rational_part assume that the numeric constant is
already a Mixed Number, with nested whole_part and
rational_part typedefs. Any numeric constant that
wants to be treated as a Mixed Number but can't
provide these typedefs (e.g. double_c) must provide
the necessary metafunction class specializations.
However, for Rational Constants, whole_part and
rational_part can be specialized in terms of the
numerator and denominator metafunctions. If there are
at least two such models of Rational Constants, the
specialization code of whole_part and rational_part
would have to be duplicated for each model. The
macros are there to minimize this duplication. The
same goes for the numerator and denominator of Mixed
Numbers.
[snip concepts discussion, started on new thread]
> Also, Cromwell, do you think that rational numerator
> and denominator should be evaluated eagerly (as it
> currently is) or alternatively lazily, so that it
> would need some function to normalise the rational
> before or maybe during math?
I've exposed simplified_rational for use by those
metafunctions that are guaranteed to return relatively
prime numerators and denominators, e.g.
rational_part_impl<double_tag>::apply. Those numeric
metafunctions that cannot provide this guarantee must
use either rational or rational_::simplify.
> (FWIW my vote is to stay with current behaviour
> though using rational<numerator,denominator> for
> ::type member.)
Is the current definition sufficient?
template <typename N, typename D>
struct rational : rational_::simplify<N,D>::type
{
};
> Meanwhile keep up the good work..
Thanks!
Cromwell D. Enage
__________________________________
Yahoo! Mail  PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk