Re: [boost] Re: Re: rational with finite precision

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-12-12 16:48:18

On Sun, 12 Dec 2004 13:47:54 -0700, Jonathan Turkanis wrote
> > imho with a built-in type rational<> has more issues than float,
> > and not just precision, but also garbage instead of rounding, and
> > it is likely to affect even simple uses
> 
> >> It sounds like you are describing a numeric type which could coexist
> >> with boost::rational. Perhaps you should implement it and post it.
> >
> > it does not necessarily have to be separate from rational<>
> 
> Yes, I got that part ;-)

But it would be nice if it was extracted from rational<> to make it more
general purpose.

> > if there is interest in using it, but no one is interested
> > in implementing it, and it is not a problem that it will
> > take months for me (end of semester, exams time) then yes,
> > i can do it
> 
> Okay, let's see if there's interest.

Well, I have some interest in the general problems of number type
representations / problems -- so I'm interested.  And let me see if I can
expand the scope and motivate others ;-)

In date-time there are a number of little number utilities -- some should
probably come out as first class libraries with docs instead of being buried
as implementations.  For example, there is date-time/int_adapter.hpp -- a
template that adapts an integer to allow for special values (infinities and
not a number).  constrained_value  (fancier version written up in last months'
CUJ) that effectively prevents assignment, etc to an integer outside a
compile-time defined range (eg: seconds are always 0-60) -- has policy-based
error handling.  wrapping_int creates a integer type that 'wraps around' on
adding or subtracting. So, for example, if the range is 1-12 if value is 11
and you add 2 you get 1.  This might be handy in creating good behavior for
and angle class -- values always 0-360. The issues you raise w.r.t to rounding
etc are things that have general application.

Finally, it would be nice if someone would actually submit infinite precision
number types and resurrect the fixed decimal proposal (it died after it was
rejected in review).  The rounding and accuracy functions contained in these
types are nasty to get right and it's sad that, once again, C++ programmers
are left on their own to solve one of these issues. Java, for example, has
BigInteger and BigDecimal types available -- lots of scripting languages have
these types. (Oh, and yes I know there are some of these classes out there as
open source, but let's get them into Boost!)

Jeff