Re: [boost] Boost::Bigint header draft - suggestions are welcome!
Date: Mon, 7 May 2007 09:31:28 -0400 From: "Jarrad Waterloo" jwaterloo@dynamicquest.com
Could use constructors that take 64 bit integers
There wass a problem with this approach, but it seems that defining 4 constructors (int, unsigned int, uint64, int64) satisfies all needs. Will do. Yes, wchar_t and wstring support is required Added to todo list. conversion to and from string probably should go into static function; other
people's preference
I followed the way things like stringstream and boost::format behave. Suggestion noted though, I'd like to hear other opinions. Could we have conversions to and from strings of different bases 2-36 Indeed, I don't know why I missed it. Added to todo list.
From what I have read from other bigint and other boost api's serialization is prefered if it was in a seperate header so that it won't become part of the build if not used.
Sorry, that was indeed unclear. I merged 2 headers in 1 for posting here, serialization is in a separate header. 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@inter.nl.net
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!
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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Arseny Kapoulkine Sent: Monday, May 07, 2007 10:59 AM To: boost@lists.boost.org 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@inter.nl.net
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
participants (2)
-
Arseny Kapoulkine -
Jarrad Waterloo