Re: [boost] Boost::Bigint header draft - suggestions are welcome!

From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2007-05-07 12:00:04

I'll address last first.

Think C bit fields, example follows:
struct packed_struct {
                 unsigned int f1:1;
                 unsigned int f2:1;
                 unsigned int f3:1;
                 unsigned int f4:1;
                 unsigned int type:4;
                 unsigned int funny_int:9;
} pack;
I would imagine this would only be needed with unsigned big ints. I wasn't
paying attention that yours covers unsigned as well.
In any case in barcode and rfid identification the item id, product type,
company and other data may all be included into one unsigned integer.
So at least 2 methods one for getting and setting the values of a n bit sub
integer within the infinite integer would help. Multiple designs some
utilize bit mask so the process can be repeated faster but I have only saw
those on 'bigger ints'.

Now onto GMP big_int on the stack, I know of it but have never used it as I
couldn't get it compiled on Windows and those with the knowledge are tight
lipped. In any case, I thought they were a set of C functions that can work
on int arrays whether heap or stack allocated. If that is the case why
wouldn't it have a stack implementation!

On a side note: I don't know how this will go over with other boost members.
But could this be driver based. What I mean is the default implementation is
the standard C++ approach which would always exist but if a faster one
exists such as GMP that that is used. Does GMP versus standard has to be a
part of the objects type? Just a thought but the important thing is to
finally get an infinite int library.

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Arseny Kapoulkine
Sent: Monday, May 07, 2007 10:59 AM
To: boost_at_[hidden]
Subject: Re: [boost] Boost::Bigint header draft - suggestions are welcome!

...

On a side note sometimes people need bigger_ints that are not of infinite
> precision that could be created on the stack. Problem domains would
> include
> RFID and other identification schemes. As such it would be nice to have
> the
> following:
> Ability to created a stack allocated bigger_int<128> similar in design to
> the bitset

As I noted this will not be supported for all implementations because of
increased complexity. The library initially will contain 2 implementations,
one will be faster and will be based on GMP - this implementation will NOT
support stack-based allocation. Another implementation will allow for
arbitrary storage implementation that meets the interface constraints,
possible syntax will be

bigint_base<bigint_default_implementation<bigint_static_storage<256> > > (oh
wel, I guess I will need to provide a helper, something like
static_bigint<256>::type)

2nd to be able get and set sub integers for instance give me the integer at
> bit 7 and goes for 21 bits.

I don't quite get it, do you want the ability to fetch separate bits or
separate limbs (digits, etc. - the internal representation)? And anyway,
what do you need it for? What behavior do you want for it in case of for
example negative numbers?

> Other proposals out there for review are Proposal for an Infinite
> Precision
> Integer for Library Technical Report 2 Draft by M.Kronenburg_at_[hidden]

I'd be happy to look at it, but I found only the initial post that said the
pdf is in Boost Vault - but it seems it is not there any more.

Thank you for your answer!
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost