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
