Re: [boost] RE: Standardization of Boost libraries

From: Chuck Allison (cda_at_[hidden])
Date: 2002-03-08 15:44:38

I must say that the argument that since we have complex we should also have
rational makes a lot of sense to me (another mathematician :-). Ironic,
since at Redmond I was one of those who questioned the need for rational to
be included in the standard C++ library. I stand converted.

----- Original Message -----
From: "Moore, Paul" <paul.moore_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Home (E-mail)" <gustav_at_[hidden]>
Sent: Friday, March 08, 2002 3:27 AM
Subject: [boost] RE: Standardization of Boost libraries

> 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
>
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>