2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <sven@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/BIP39Mnemo... Esteban A. Maringolo