Re: [boost] Request for interest in new library : Bit Logic
(oops hit reply-to-sender, not list ) Begin forwarded message:
From: Art Stamness <artstamness@yahoo.com> Date: January 31, 2007 5:11:21 PM PST To: me22 <me22.ca@gmail.com> Subject: Re: [boost] Request for interest in new library : Bit Logic
On Jan 31, 2007, at 4:21 PM, me22 wrote:
On 1/31/07, Art Stamness <artstamness@yahoo.com> wrote:
Any feedback, positive, negative, suggestions is always appreciated. Also if there is a better suggestion for a name, I am open to it. I realize the Boost.Logic library has a very different purpose than this one, and don't want them to be confused.
Boost.Bitwise, maybe?
Typo: http://www.emulogic.com/bit_logic/bit_vector/index.html "middle of the container is dones in"
Thanks, corrected now.
Regarding the implementation, smallest_bit_storage would probably be better off using Boost.Integer's facilities or a trick like is using in uint_t to avoid requiring the specifically-sized types.
Those types are limited by the largest integral type of the system. This library is intended for modeling small and large types. I should have made it more clear in the examples in the documentation. Ex. a bit_array<100> is a perfectly valid type. while a boost::int_t<100> is not.
However, what's the main advantage of your code over Boost.Dynamic_Bitset and std::bitset? It seems (from a quick look) that your bit_array is close to std::bitset and your bit_vector is close to at least one of dynamic_bitset and vector<bool> (the latter being specialised for packing).
True, these types are similar to the std::bitset / boost::dynamic_bitset / std::vector<bool> in that they are used to represent bit data. However they have a very different operational semantic. These types are intended to model bit containers for arbitrary logic functions. Things that are commonly found when modeling hardware systems ( you can find why i do this under the "Motivation" section ).
For instance, taking 4 bits from one type and 4 bits from another, doing a logical exclusive-or on those bits, and placing it in 4 bits of a third type is a 1 line operation.
c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all be bit_array / bit_vector / bit_container ( adapted type )
This very closely mimics what is found in hardware description languages ( which is my background ) .
c[15:12] = a[7:4] ^ b[3:0] ; // Same operation in Verilog
This library is intended to provide fixed , and resizable types, that can be used to model n-bit long logical operations in a clear semantic description, while also providing some STL container like interface for use with STL algorithm.
The above listed operations would be very difficult to do with any of the 3 listed types.
Thank you for taking the time to look and comment, I hope I have answered your questions.
-Art
On Wed, 31 Jan 2007, Art Stamness wrote:
On Jan 31, 2007, at 4:21 PM, me22 wrote:
On 1/31/07, Art Stamness <artstamness@yahoo.com> wrote:
However, what's the main advantage of your code over Boost.Dynamic_Bitset and std::bitset? It seems (from a quick look) that your bit_array is close to std::bitset and your bit_vector is close to at least one of dynamic_bitset and vector<bool> (the latter being specialised for packing).
True, these types are similar to the std::bitset / boost::dynamic_bitset / std::vector<bool> in that they are used to represent bit data. However they have a very different operational semantic. These types are intended to model bit containers for arbitrary logic functions. Things that are commonly found when modeling hardware systems ( you can find why i do this under the "Motivation" section ).
For instance, taking 4 bits from one type and 4 bits from another, doing a logical exclusive-or on those bits, and placing it in 4 bits of a third type is a 1 line operation.
c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all be bit_array / bit_vector / bit_container ( adapted type )
This very closely mimics what is found in hardware description languages ( which is my background ) .
c[15:12] = a[7:4] ^ b[3:0] ; // Same operation in Verilog
This library is intended to provide fixed , and resizable types, that can be used to model n-bit long logical operations in a clear semantic description, while also providing some STL container like interface for use with STL algorithm.
The above listed operations would be very difficult to do with any of the 3 listed types.
How about writing bit container algorithms instead of new bit containers? Taking the 'select' example, we could write: select(c,15,12) = select(a,7,4) ^ select(b,3.0) The 'select' algorithm would return a view for a range of bits. Thus we would only need to write those algorithms plus some view classes, and it could work with any already existing bit containers. It could be possible to specialize the views for certain types of containers if it could optimize some operations (I don't know). -- François Duranleau LIGUM, Université de Montréal
On Feb 1, 2007, at 7:03 AM, François Duranleau wrote:
On Wed, 31 Jan 2007, Art Stamness wrote:
On Jan 31, 2007, at 4:21 PM, me22 wrote:
On 1/31/07, Art Stamness <artstamness@yahoo.com> wrote:
However, what's the main advantage of your code over Boost.Dynamic_Bitset and std::bitset? It seems (from a quick look) that your bit_array is close to std::bitset and your bit_vector is close to at least one of dynamic_bitset and vector<bool> (the latter being specialised for packing).
True, these types are similar to the std::bitset / boost::dynamic_bitset / std::vector<bool> in that they are used to represent bit data. However they have a very different operational semantic. These types are intended to model bit containers for arbitrary logic functions. Things that are commonly found when modeling hardware systems ( you can find why i do this under the "Motivation" section ).
For instance, taking 4 bits from one type and 4 bits from another, doing a logical exclusive-or on those bits, and placing it in 4 bits of a third type is a 1 line operation.
c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all be bit_array / bit_vector / bit_container ( adapted type )
This very closely mimics what is found in hardware description languages ( which is my background ) .
c[15:12] = a[7:4] ^ b[3:0] ; // Same operation in Verilog
This library is intended to provide fixed , and resizable types, that can be used to model n-bit long logical operations in a clear semantic description, while also providing some STL container like interface for use with STL algorithm.
The above listed operations would be very difficult to do with any of the 3 listed types.
How about writing bit container algorithms instead of new bit containers? Taking the 'select' example, we could write:
select(c,15,12) = select(a,7,4) ^ select(b,3.0)
The 'select' algorithm would return a view for a range of bits. Thus we would only need to write those algorithms plus some view classes, and it could work with any already existing bit containers. It could be possible to specialize the views for certain types of containers if it could optimize some operations (I don't know).
This was a consideration. The problem is that I cannot create a "3- bit type", in any of the existing bit storage types ( uint8_t for example ) and still check for errors if the 4th bit is used. I wanted a strongly typed container system. The bit_container_adaptor class ( not documented, err well ) allows for taking any existing bit storage type, and providing the bit container functions. This will automatically size to the actual bit count of the container. so every data type would be a 2^n sized. That is not to say that adding select_bits as a free function isn't a good idea. Let me add that now ( the base functionality is there, it just does not exist as a function today ) . Thanks for the feedback. -Art p.s. Cromwell and Chris, I am working on providing responses to your earlier questions / comments.
participants (2)
-
Art Stamness -
François Duranleau