Re: Extended binary numbers

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-20 14:52:12

--- In boost_at_[hidden], Daryle Walker <darylew_at_m...> wrote:
> The file "bitint.zip," my first independent contribution, was 
uploaded to
> the Boost vault.  It should work like a lot of built-in unsigned 
integer
> implementations do: two-complement handling of a binary 
representation.
> Operations work like they did in computer science classes (or at 
least to
> the best I can remember or make up).  They can support arbitrary 
sizes (it's
> a template type based on the size, so the size is per type, not per 
object).
> The documentation was done similar to the rational<> docs.
> 
> Opinions?

Nice.  My binary algebra is more than a little rusty, so I won't 
comment too much on the mathematics.  I do have a few comments in 
general, however.

boost::unsigned_char_bitint and cousins are pointless and shouldn't 
exist.  They're fine as typedefs within your test harness, but there 
is no reason to have them within the header.  Why?  Because the size 
is implementation defined and the implementation will be slower than 
the compiler implementation equivalents.  In other words, no one will 
ever use them in real code.

The real use of boost::bitint is in using specific bit sized integers 
when they don't exist on specific platforms.  In other words, 
boost::bitint<64> would be a great candidate for int64_t on those 
platforms that don't have a built in 64 bit integer.  Yes, it'll be 
slower on those platforms, but at least you can code to them using a 
simple, portable interface!

I dislike the fact that bitint really only supports unsigned 
integers.  I'd rather see both a bitint and an unsigned_bitint, which 
shouldn't be difficult to do.

Also, I'd *really* like to see the related class bigint (or some 
other name), which is an arbitrarily sized integer type that scales 
to larger sizes as needed.  The bitint class is easier to deal with, 
and will work for 90% of the cases where you need large integral 
types, but those 10% cases would be nice to cater to as well.  Along 
these same lines we could use a bigfloat as well.  This type might 
use a fixed point representation and bigint in order to avoid the 
normal binary to decimal conversion error.

You get the idea.  There are a lot of different numeric types that 
would be quite beneficial to have in the language.  I really don't 
know where you'd want to draw the line on which to include and which 
not to.

Bill Kempf