Please, if you do implement something, start with a Collection class and call it something like BitArray. It might be appropriate to subclass under ByteArray, but perhaps not.
On Mar 4, 2018 12:45 PM, "Esteban A. Maringolo" <emaring...@gmail.com> wrote: > 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>: > > Bits are actually numbered from right to left (seen from how they are > printed). > > I understand bit operations, used it extensively with IP address eons ago. > > But if a spec says: "Take the first n bits from the hash", it means > the first significant bits. > so in 2r100101111 the first 3 bits are "100" and not "111". > > > But in a fixed amount of bits you could indeed number them the other way > around. > > It does not matter that you write the leading zeros or not, everything > to the left is zero anyway. When shifting, the right thing happens. > > If it were a packet, with a fixed size, and the header started with 0, > then the leading zeros matter. > > So in my use case it isn't the same "00000000000000000000000000000000" > than "000000000000000000000000000000000000000000000000" (both in hex > notation). > See [1] > > > Adding something like Integer>>#bitSliceFrom:to:size: based on your > reverse numbering would be wrong, IMHO. > > Yes, it would be wrong. Unless you have to option to specify the > endianess you want to use. > > > I guess you could write it like > > > > n := 2r11110000101010001111000011110000. > > from := 8. > > to := 13. > > size := 32. > > (n >> (size - 13)) bitAnd: ((1 << ( to - from + 1)) - 1). > > > > But the size feels out of place. > > How so? > > Thanks in advance, this is super low priority, I just wanted to check > whether something like that already existed. > > Regards! > > > [1] https://github.com/eMaringolo/pharo-bip39mnemonic/blob/ > master/src/BIP39Mnemonic-Core.package/BIP39MnemonicTest.class/instance/ > jsonTestVectors.st > > > Esteban A. Maringolo > >
