Hey Guys,
I think i do understand this.
redis> SET mykey "foobar"
"OK"
redis> BITCOUNT mykey
(integer) 26
Can some one please explain why we get 4 & 6? I assumed we are counting the bits from the given position range. From 0 to 0, the bitcount max can be only 1. how can it be 4 or 6 ?
redis> BITCOUNT mykey 0 0
(integer) 4
redis> BITCOUNT mykey 1 1
(integer) 6
Question:
How to count the bits in the given range?
Comment From: ptjm
bitcount mykey 0 5 (integer) 26
the start and end are byte indices
Comment From: huangzhw
@oranagra I think whether we can make bitcount to BITCOUNT key [start end [BIT|BYTE]].
Bit index is more reasonable.
Comment From: oranagra
@huangzhw i'm not sure what's the popular use case for this command and whether or not it is more reasonable. @itamarhaber can you comment? did you hear similar requests in the past? I don't see a disadvantage in adding that option, but i'm not sure a good trigger for that is a question that arose from not reading the docs (not sure it'll prevent confusion). so we need to consider if that's useful, and if it is, then let's add it. @kitkars do you need bit offsets counting for your use case? can you elaborate?
Comment From: kitkars
@oranagra @itamarhaber
when setbit command provides exact bit offset, why bitcount uses byte offset. ? It is fine to have byte offset. but also provide an option for bit offset.
Below is just an example. There could be other ways to do this. but I am using this to explain.
For ex: lets imagine, I am using bitwise operation to track an user login history.
The bit offset is YYYYMMDD.
setbit user:1:login 20190301 1
setbit user:1:login 20190302 1
setbit user:1:login 20190318 1
setbit user:1:login 20190420 1
How many times the user logged in the month of March 2019? This should return 3.
BITCOUNT user:1:login 20190301 20190331 BIT
Comment From: oranagra
Ok, it was easy to convince me.
looking further, in related commands (SETBIT, GETBIT, BITPOS, and BITCOUNT)
i see that SETBIT and GETBIT are obviously about bit offsets.
bit count was as reported here about BYTE offsets.
but BITPOS also has issues. the position it returns is a bit position, but the start and end arguments are in byte offsets.
ideally, we would have been able to just change all of these to bit offsets (user can easily multiply by 8 on his side), but obviously due to backwards compatibility, we can't.
so i agree with @huangzhw proposal about adding a [BIT|BYTE] optional argument, and i think we should do that to both BITCOUNT and BITPOS.
Comment From: kitkars
@oranagra @huangzhw Thank you both. Looking forward to this feature.
Comment From: huangzhw
@oranagra What about BITPOS.
BITPOS key bit [start [end [BIT|BYTE]]]
or
BITPOS key bit [start [end] [BIT|BYTE]]
Comment From: oranagra
i prefer the first one. i.e. all arguments are still positional.
we could have also make it take unit suffixes i.e. start and end can be 123bit or 123byte (something we have in configs), but not in commands.
so let's model it similar to the units of GEORADIUS
Comment From: huangzhw
You mean we add a config to choose the default is BIT or BYTE?
So BITCOUNT key 10 20, the index can be bit or byte?
Comment From: oranagra
no, i meant that we have a suffix in CONFIG SET maxmemory 1gb
i.e. all configs that take a size in bytes, can be either used with a plain number, or a number with a suffix.
but we don't have that in commands, so i dismissed the possibility of adding support for it like BIGPOS <key> <bit> 123bit 50byte
and instead i suggest to take the first option you gave (BITPOS key bit [start [end [BIT|BYTE]]]) this means that all arguments are positional (they have a fixed position), and you can only add more arguments if you didn't omit the ones before them.
Comment From: huangzhw
OK. I understand. A config change the default behavior may be useful. WDYT?
Comment From: oranagra
no, i think a config option that changes the behavior of a command is very wrong. configs can enable or disable features or tune performance, but having one that will change a valid command argument to have a different meaning is wrong. the trivial thing here is to either extend the command with more arguments or improved syntax, or create a new command...
Comment From: huangzhw
OK. I know. Thanks.