Boost::Bigint header draft - suggestions are welcome!
Hello, I am the student that was lucky enough to be selected as the developer of Boost Bigint library as a Summer Of Code project. I've started working on the project earlier than I had to, and there is a header draft ready which I'd like to share with you - there are some issues that are not quite clear (I've marked them with comments), and I would very much like to hear possible problems with the current interface/suggestions about improvement/etc. The header is here: http://zeux.info/pub/soc/header.hpp (the SVN repository was just set up, so I did not have enough time to upload all necessary files to it). Note, that while the reference (GMP-based) implementation is more than 50% done (actually, it's almost done, some issues with string conversion and 64-bit correctness remain), I've stripped everything related to implementation from the header - implementation is subject to change, it's not finished, and possible interface changes could affect either the implementation class interface or the actual implementation. The suggestions that ARE known: - the bigint class may benefit from expression templates/move semantics regardless of the actual implementation behind the scenes. This is a known thing, and I'll address it once all base things (stable header, 2 stable implementation, test suite, documentation) are finished - initially the approach that allowed to freely mix implementation strategy (i.e. performing calculations) and storage strategy (memory management) was selected, but after concept drafts it was clear that it will restrict the possible implementations or make writing a wrapper for existing libraries too complicated or even impossible. Now the implementation has to performn its own memory management, though the default implementation (portable C++ one which will not depend on any third-party libraries) will provide a reusable storage strategy (if that was unclear, bigint_base<bigint_default_implementation<some_custom_strategy_that_performs_custom_memory_manager>
).
Thanks in advance.
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
Could use constructors that take 64 bit integers Yes, wchar_t and wstring support is required conversion to and from string probably should go into static function; other people's preference Could we have conversions to and from strings of different bases 2-36 the build if not used. 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 2nd to be able get and set sub integers for instance give me the integer at bit 7 and goes for 21 bits. 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 -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Arseny Kapoulkine Sent: Monday, May 07, 2007 8:54 AM To: boost@lists.boost.org Subject: [boost] Boost::Bigint header draft - suggestions are welcome! Hello, I am the student that was lucky enough to be selected as the developer of Boost Bigint library as a Summer Of Code project. I've started working on the project earlier than I had to, and there is a header draft ready which I'd like to share with you - there are some issues that are not quite clear (I've marked them with comments), and I would very much like to hear possible problems with the current interface/suggestions about improvement/etc. The header is here: http://zeux.info/pub/soc/header.hpp (the SVN repository was just set up, so I did not have enough time to upload all necessary files to it). Note, that while the reference (GMP-based) implementation is more than 50% done (actually, it's almost done, some issues with string conversion and 64-bit correctness remain), I've stripped everything related to implementation from the header - implementation is subject to change, it's not finished, and possible interface changes could affect either the implementation class interface or the actual implementation. The suggestions that ARE known: - the bigint class may benefit from expression templates/move semantics regardless of the actual implementation behind the scenes. This is a known thing, and I'll address it once all base things (stable header, 2 stable implementation, test suite, documentation) are finished - initially the approach that allowed to freely mix implementation strategy (i.e. performing calculations) and storage strategy (memory management) was selected, but after concept drafts it was clear that it will restrict the possible implementations or make writing a wrapper for existing libraries too complicated or even impossible. Now the implementation has to performn its own memory management, though the default implementation (portable C++ one which will not depend on any third-party libraries) will provide a reusable storage strategy (if that was unclear, bigint_base<bigint_default_implementation<some_custom_strategy_that_performs _custom_memory_manager>
).
Thanks in advance. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
Could use constructors that take 64 bit integers Yes, wchar_t and wstring support is required conversion to and from string probably should go into static function; other people's preference Could we have conversions to and from strings of different bases 2-36 the build if not used.
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
"Jarrad Waterloo" wrote in message... the
following: Ability to created a stack allocated bigger_int<128> similar in design to the bitset 2nd to be able get and set sub integers for instance give me the integer at bit 7 and goes for 21 bits.
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
Yes, that is N2143 on http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01 Currently I am working (in my free time) on an implementation, which will also have assembler for x86, and will thus be only a little slower than GMP on x86. An integer allocated on the stack will I suppose be about as fast as an integer allocated in a memory pool. Also I will add a memory pool allocator to my implementation. The problem I see with a fixed size integer is that everyone will be using different sizes for essentially the same problems. How should the programmer choose the size to be used? Regards, Maarten.
Arseny wrote:
I am the student that was lucky enough to be selected as the developer of Boost Bigint library as a Summer Of Code project. I've started working on the project earlier than I had to, and there is a header draft ready which I'd like to share with you - there are some issues that are not quite clear (I've marked them with comments), and I would very much like to hear possible problems with the current interface/suggestions about improvement/etc.
Looks good. Some quick thoughts: - Have you considered conversions to/from floating-point? - Have you considered using Boost.Operators? - Are logical operations well defined for negative operands with different numbers of bits? (e.g. -1 | 12345) Also, what does ~ do? Are different signed and unsigned types needed? - I take it that this class dynamically allocated enough memory for the value. Can you quantify the performance penalty that this imposes compared to declaring the number of bits in advance (e.g. bigint<256>) and statically allocating that much memory? You may have seen my posts here about a fixed point library recently. I currently use Boost.Integer to choose int8_t, int16_t, int32_t or int64_t as an implementation type. It would be useful to be able to use bigint as an implementation type when the number of bits required exceeds 64. Regards, Phil.
participants (4)
-
Arseny Kapoulkine -
Jarrad Waterloo -
Maarten Kronenburg -
Phil Endecott