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