I now have a working implementation of fraction_c and rational_c, as well as arithmetic metafunctions that operate on them, at <http://groups.yahoo.com/group/boost/files/mpl_math.zip> (tested on MinGW 3.2 and MSVC 7.1). --- Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Well, the ideal solution is outlined in
http://article.gmane.org/gmane.comp.lib.boost.user/5668/,
but for the purpose of implementing the functionality itself I suggest you abstract from all these complications and simply name these as you wish, e.g. 'fp_plus', 'fp_minus', etc., or anything along these lines.
Yeah, I'll hold off on implicit rational-to-fixed conversions et. al. for a while.
2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this:
template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; };
If it gives us a satisfactionary range of representable values, sure.
Hmmm, maybe it won't. A decimal of sufficient size may be out of the value range that a rational (which I've actually implemented as a fraction) may represent; likewise, no decimal in mathematical existence can exactly represent, say, one-third.
3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how?
Within the wrapper struct, in form of a conversion operator, so we can write something like
typedef float_<2,718281828> e; std::cout << e;
Ah, haven't done that yet. What I've done for the moment was something like this: typedef rational_c<int,4,5,8> shoe_size; typedef rational_wrapper<float,shoe_size> shoe_wrap; std::cout << shoe_wrap::value(); That's what I actually meant by wrapper struct, but if you want me to use a default return type, I should be able to reduce the code down to your type of syntax. My current focus with regard to this endeavour is to provide a compile-time, arbitrary-precision integer that looks like this: typedef big_integer<positive_sign,2,9,9,7,9,2,4,5,8> metric_speed_of_light; typedef big_integer<negative_sign,9,0,0,0,0,0,0,0,0,0> coulomb_constant; Once I get it to work, I should be able to roll out big_fraction and big_rational the same way I did fraction_c and rational_c, after which I'll consider building fixed_c on top of big_rational. The challenge I face now, of course, is getting big_integer to work. Right now I could wrap the digits in a vector_c, with the unspecified digits set to -1, then perhaps use iter_fold_backward to convert it into a little-endian digit sequence so I could process the value more easily. I believe the issue there is that the user has to #define BOOST_MPL_LIMITS_VECTOR_SIZE before #including big_integer in order to increase the precision beyond 10 digits, right? What should I do in this case? BTW, how and where should I provide MPL lambda support, if at all? Admittedly I have no idea how that works. Cromwell Enage __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/