Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)
âAs I understand it, the OP's problem is that he wants to count bits from the high end, and Integers don't *have* a finite high end. PL/I has bit strings. Common Lisp has bit strings. Some Schemes have copied Lisp. Eiffel _had_ bit strings, more or less, but dropped them. Smalltalk/X has a BitArray class; see http://live.exept.de/ClassDoc/classDocOf:,BitArray for documentation. My own Smalltalk also has a BitArray class with a somewhat different interface. Although developed independently, both are implemented as byte arrays with an associated count. It's not terribly hard. For selecting small numbers of bits out of long bit strings, this is more efficient than shifting and masking a large integer. I rather wonder whether it might be possible to do better by thinking in a somewhat less C-like style. For example, Erlang handles unpacking network packets and the like by letting you write bit-string *patterns*, which the compiler can then generate special-case code for. Run-time generation of small amounts of code is somewhat easier in Smalltalk. (Most Smalltalks.) What would it be like if you had a BitArray class where you could say extractor := BitArray extractorForBits: 3 to: 7 of: 256. ... extractor value: thisPacket and extractor was a block (possibly cached) with code specialised for just that case?
It looks like having BitArray is a good approach. Is there a MIT compatible version? I could add it to my collection collection :) Containers I should migrate it to github. Stef On Mon, Mar 5, 2018 at 2:52 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
As I understand it, the OP's problem is that he wants to count bits from the high end, and Integers don't *have* a finite high end.
PL/I has bit strings. Common Lisp has bit strings. Some Schemes have copied Lisp. Eiffel _had_ bit strings, more or less, but dropped them.
Smalltalk/X has a BitArray class; see http://live.exept.de/ClassDoc/classDocOf:,BitArray for documentation.
My own Smalltalk also has a BitArray class with a somewhat different interface. Although developed independently, both are implemented as byte arrays with an associated count. It's not terribly hard. For selecting small numbers of bits out of long bit strings, this is more efficient than shifting and masking a large integer.
I rather wonder whether it might be possible to do better by thinking in a somewhat less C-like style. For example, Erlang handles unpacking network packets and the like by letting you write bit-string *patterns*, which the compiler can then generate special-case code for.
Run-time generation of small amounts of code is somewhat easier in Smalltalk. (Most Smalltalks.) What would it be like if you had a BitArray class where you could say extractor := BitArray extractorForBits: 3 to: 7 of: 256. ... extractor value: thisPacket and extractor was a block (possibly cached) with code specialised for just that case?
On Mon, Mar 5, 2018 at 2:52 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
âAs I understand it, the OP's problem is that he wants to count bits from the high end, and Integers don't *have* a finite high end.
PL/I has bit strings. Common Lisp has bit strings. Some Schemes have copied Lisp. Eiffel _had_ bit strings, more or less, but dropped them.
Smalltalk/X has a BitArray class; see http://live.exept.de/ClassDoc/classDocOf:,BitArray for documentation.
âGreat documentation ! We need something like that for Pharo classes. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/
2018-03-05 10:52 GMT-03:00 Richard O'Keefe <raoknz@gmail.com>:
As I understand it, the OP's problem is that he wants to count bits from the high end, and Integers don't *have* a finite high end.
Exactly. I want to work with a block of bits, today the best proxy for that is using an Integer.
Smalltalk/X has a BitArray class; see http://live.exept.de/ClassDoc/classDocOf:,BitArray for documentation.
This class basically does the job. Thank you for the reference. Esteban A. Maringolo
participants (4)
-
Esteban A. Maringolo -
Richard O'Keefe -
Serge Stinckwich -
Stephane Ducasse