-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a bitequal() function #9
base: master
Are you sure you want to change the base?
Conversation
Pythons list implementation has a special case to ensure that x.extend(x) is the same as x.extend(list(x)). i.e. it doesn't notice changes to the size of the list during the extend. Previously this case would not have been handled correctly by bitarray. This changes that by checking what the size of the other array is before we make any changes. This ensures both that this works correctly and also (importantly) that we don't try to write past the end of the array.
Fixed minor doc typo.
I love the left and right shift. But I think we should make theseoperator overloads so we can >> or << |
@diamondman Yes, bitdiff() may now be slower than (a ^ b).count(), since the latter uses SIMD. Ideally we should have a SIMD version of count(), bitdiff() should use SIMD and that code as well, and this new bitequal() should reuse as much of that code as possible, instead of being a copy-paste. Agreed that lshift() and rshift() should be hooked to python's >> and << instead. Also, these versions claim that they only work on big endian machines, and are not tested, which seems bad. As for using SIMD for shifts: in short, it only works for constant shifts or multiples of 8. If we use |
I agree the big endian only is a problem. Maybe there is something woth doing with shifting with SIMD multiples of 8 and then doing the rest of shiftcount%8 shift as a second operation. It would cause double writes, but maybe it would be faster than an arbitrary shift operation. I will try to look into this in a bit. |
The code in this PR does move around the bytes first, so that is a spot for SIMD! 0fd042e#diff-1997c64b6c87f3a5197c717a65138709R2412 |
bitarray/_bitarray.c
Outdated
} | ||
|
||
#define aa ((bitarrayobject *) a) | ||
#define bb ((bitarrayobject *) b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should prefer using variables here.
bitarray/_bitarray.c
Outdated
@@ -2925,6 +3079,48 @@ static PyTypeObject Bitarraytype = { | |||
/*************************** Module functions **********************/ | |||
|
|||
static PyObject * | |||
bitequal(PyObject *self, PyObject *args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this a module method instead of being on the instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing because bitdiff() is not a method. Arguably they both should be methods, and the names could be more clear, like count_equal() and count_different().
- fixed a problem in cases a < b when self == other. Source memory was overwritten.
The previous wording made it sound like the function did the opposite of what it actually does.
Hi guys, is there still need in simple shifts? As I found here, it was not merged. So, I need this implementation and have time to commit it. |
I think it would be a shame to let this PR deteriorate further... |
You are right. I'll create a new one so I have it already implemented. |
DOC: improve description of fill()
Handle extending self correctly
…ey are treated for lists
… update README to pass Python 3 doctest
I added a bitequal() function to calculate the same as (a & b).count().
Thanks for this great library.
Björn
This PR was moved from ilanschnell/pull/8.