[sorry for sending this twice Howard] Hi Howard, 2008/6/19 Howard Hinnant <hinnant@twcny.rr.com>:

<nod> Thanks Daren!

The boost email server seems really slow (dead?) today. Here's the response I sent over 2 hours ago:

Thanks for doing this Darren (sorry about misspelling your name). A few comments below...

No problem. I'm getting emails through sporadically too. On Jun 18, 2008, at 11:48 PM, Darren Garvey wrote:

...

... are sign() and abs() supposed to be runtime functions? I implemented them as meta-functions - I'm sure these are in boost somewhere, I just don't know where. Maybe compilers are generally clever enough, or the standard guarantees those functions will be evaluated at compile time? I'm never sure where the line is drawn on this one...

They have to execute at compile time. Whether or not the C++0X constexpr feature can be brought to bear here I really don't know. In my example implementation they were simply "__"-prefixed meta functions.

Ok. I think in context it's perfectly clear then.

The main limitation is that it uses

...

static_gcd<> from Boost.Math. That meta-function is parametrised with `unsigned long` instead of `intmax_t` which limits how big the allowed numbers can be.

This is a show-stopper. One of the basic features of ratio is that you can throw any integral value at it, and it will either hand back the right answer or refuse to compile.

I did actually get that impression from the text, although I have to admit I miss-remembered one paragraph: If R1::num * R2::den < R2::num * R1::den, ratio_less derives from true_type,

else derives from false_type. Implementations are permitted to use more complex algorithms to compute the above relationship to avoid overflow. If the implementation is not able to avoid overflow, a diagnostic shall be emitted.

Being really nit-picky: It makes no difference semantically, but I think the second and third sentences could possibly do with being the other way around (or thereabouts), since the third is more important than the second. Maybe C++ was making my brain expect the optional features in a feature-list to come after the non-optional ones? ;-)

Some worrisome results:

typedef boost::utility::ratio<1, 0x8000000000000000LL> R9; std::cout << R9::num << '/' << R9::den << '\n';

-1/-9223372036854775808

This paragraph:

<snip>

...

was intended to cause the above example to fail to compile because abs(0x8000000000000000) < 0.

I didn't know you could do that to check for overflow. I think I fixed it in my experimental implementation, using BOOST_MPL_ASSERT_MSG for some spiffy diagnostics.

Once we have an intmax_t-based gcd, the ratio arithmetic and less-than comparison will need more work to detect overflow and subsequently refuse to compile:

I've attached a version of static_gcd which uses intmax_t, although I can't find the relevant bit of the Boost.Math test-suite to check it properly.

In general, N2615 is sprinkled liberally with "diagnostic required". Errors which can be detected at compile time

are actively sought out.

I think I've added the necessary diagnostics to the ratio class itself, but not to any of the operators yet <time passes> Ok, I've attached a 7-zipped version that does have the operators. I'm in unfamiliar territory here, so there's probably more that can be done to help with compile-time efficiency and whatnot. It also still needs some more tests on the checked_ops and the ratio operators but I've run out of time for now (and I'm sure you have a proper test-suite somewhere ;-). IIUC, I *think* that only leaves dealing with the conditionals related to the optional convenience SI typedefs. Hope that helps, Darren