Re: Standardization of Boost libraries

From: raoul45701 (kelsey_at_[hidden])
Date: 2002-03-11 00:13:09

Rational numbers W.R.T. Complex numbers.

The implementation of these two classes are very different.

1. The best implementation of complex is obvious. Anyone who used 
complex numbers and understands C++ would do it pretty much as the stl 
version. EXCEPT, no one who knows enough math to use complex numbers 
would call the square of the abs() the norm(). Hello!

2. I doubt if there is any optimal representation for rationals. I 
have used about a dozen myself. You will never find a class that makes 
more than about 30% of the users happy. The best plan might be to have 
several types, such as:

a) two fixed integers, overflow is tuff luck

b) two unlimited-precision integers. This calls for a standard 
unlimited-precision integer class, which should be done first.

c) two fixed integers, and a float to use for 'fall back' when a 
number cannot be represented. I usually use a char to indicate which 
rep is in effect.

d)two fixed integers, a fallback float, and also let the char indicate 
other events, such as plus, minus, and unsigned infinity, and NaN.

3. A method for rat_to_float is easy, but float_to_rat that correctly 
'rounds off' is hard. I am not aware if a useable algorithm is known.

That's about it, Ralph

--- In boost_at_y..., "Chuck Allison" <cda_at_f...> wrote:
> 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_a...>
> To: <boost_at_y...>
> Cc: "Home (E-mail)" <gustav_at_m...>
> Sent: Friday, March 08, 2002 3:27 AM
> Subject: [boost] RE: Standardization of Boost libraries
> 
> 
> > From: Matthew Austern <austern_at_r...>
> > > "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_y...>
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
> >
> >
> >