RE: Standardization of Boost libraries

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2002-03-08 05:27:04

From: Matthew Austern <austern_at_[hidden]>
> "Moore, Paul" wrote:
>  
> > This raises a question. As the author of the rational
> > number library, I didn't particularly do anything, or
> > get involved, regarding the inclusion of the library
> > in this list. Don't get me wrong - I don't have a
> > particular issue with this, inasmuch as I don't see
> > that there's anything much I can contribute that
> > others aren't able to handle better on my behalf. But
> > I don't recall any particular feedback on the library
> > - certainly nothing direct to me (I may have missed
> > something in the list, as traffic these days is far
> > too high for me to get through everything). Does this
> > imply that there was no comment? Or that the committee
> > accepted the library as it stands with wholehearted
> > enthusiasm :-)?
>
> It implies something a bit more odd: the committee had
> a fairly long discussion about your library, but didn't
> actually look at it! The Library Working Group decided to
> stipulate, for the purposes of the discussion, that it
> was everything we could possibly want a rational number
> library to be. We then asked: given that this is the best
> rational number library we could ask for, do we want it?
> That is, are rational numbers within the scope of what
> we're looking for?

Hmm. That may be odd, but actually, I'd say it makes perfect sense :-) At
this stage, it's entirely sensible to look at the question of whether
rational numbers are wanted in the library, before bothering too much about
how they should be implemented...

> I'd say the discussion tended toward a 'yes' answer, but
> some people weren't sure; they thought rational numbers
> might be close to the boundary between 'yes' and 'no', and
> wanted to see a few more clearcut cases before making a
> decision.

Makes sense. My point of view is that of an (ex-) mathematician, looking at
the library from a completeness point of view. In that context, having
complex numbers, but not rationals, seems odd. And from a non-mathematical
practical computing position, I have never needed complex numbers, but have
occasionally wanted rationals. (Although, in practice, I have always been
able to work around not having rationals, so I can't say I've ever had a
serious problem with the lack...)

My experience from the actual implementation process is that, without an
unlimited-precision integer type on which to base the rational class, the
usefulness of rational<> is drastically diminished. Both double and
rational<int> have subtle rounding, precision, and other issues. With
double, these properties are fairly well-known, especially by the sort of
people who are likely to hit them. With rational<int>, they are *not* well
known. On the contrary, the sort of people who might use rational<int> are
very likely to completely miss the fact that there are such problems. (I
nearly did, until I started doing the actual implementation!)

It's arguable that these sort of issues make rational<> inappropriate for
the standard library. And it's *definitely* arguable that
unlimited-precision integers are more appropriate, and should be considered
first. (One slight issue - there's no candidate implementation of
unlimited-precision integers, yet!)

> > I do have some fairly strong views on the issue
> > of keeping the library simple, for example. If
> > the committee feels that some form of baroque
> > template/specialisation/policy/traits mechanism is
> > appropriate (to allow user-level tuning of overflow
> > behaviour vs efficiency, for example) do I have any
> > voice (beyond that of any random C++ user) to say "heck,
> > no, that's not what I intended"?
>
> I think everyone on the committee would listen seriously
> to the original designer. People there are sensitive to
> the problem of trying to change something they don't
> understand. But in the end, decisions will be made by
> consensus of the Library Working Group and the committee
> as a whole. I'd certainly encourage you to come to
> meetings.

That's good to know. It's highly unlikely I'd be able to attend the
meetings, unfortunately.

My concerns were mainly based on a general feeling that recent boost
libraries have been prone to overgeneralisation, which has impacted on
portability (to sub-standard C++ compilers). Witness the recent gcd library,
which I ended up not being able to use within rational<>. In terms of the
standard library, this is probably not an issue - if a vendor ships the
standard library, it doesn't matter how it's implemented, as long as it
works. But I was trying to capture the "feel" of the std::complex
implementation - it's basically what any user would expect. I *like* the
fact that a significant proportion of the library is "nothing special", just
standardised implementations of the sort of boilerplate code people hate
having to rewrite over and over.

> In practice, I don't think anyone on the committee is
> interested in doing major redesign of libraries that get
> submitted. And in particular, I don't think anyone wants
> rational numbers to be complicated. The only change I've
> heard anyone propose is from Jay Zipnick, who wants to
> include functions to convert to and from floating-point
> numbers with a specified precision.

On that specific point, I originally planned on something like that, but
gave up when I was faced with multiple differing requirements from people
with different backgrounds. I ducked at that point on the basis that the
implementation is sufficiently exposed that anyone who wanted to could write
their own routines.

I'm not opposed to something like this, though - just totally unqualified to
judge the differing requirements :-)

Thanks for the comments,
Paul