The bottomline is breaking down most operations integer-by-integer. If
you can extract the core of nextSetBit to do it, that is fine.
You might need to introduce other methods than the 3 Jsni methods we
have discussed (it would be great to use just 3), but length() and
delete() don't fall in
I think you confused setLength() with length(). The line of code I gave
described a way to set the length of a JsArrayInteger array to an
int length. This allows us to truncate the array very quickly. It's
not absolutely neccesary, we could iterate over the array and delete()
elements one at a
Thanks for taking the time to listen, and for reviewing the code. If I
come across as overly defensive, it's only due to the amount of time
I've invested in this code. It's not due to any dislike for you, or
illusions of grandeur. I appreciate the patience you've shown me.
How about
O(N) temporary memory usage, which having the three native methods
approach (getWordPositions, setWord, getWord) is likely to have, is a
reasonable tradeoff to make since it will greatly enhance readability.
Your approach of using array indexing already saves a lot of memory as
it only uses O(N)
Using nextSetBit() repeatedly is a non-starter since compared to the
integer-by-integer approach, every operation will be bit-by-bit. This
will be
x-times slower, where x is the average number of bits set in an
integer.
I guess I wasn't clear in this regard, I was talking about just
Thanks for getting back to me on this. I'll respond to the 5 issues
here, saving the first issue for last, as it's the longest and it's
easier to just skip over if it's not important to you, or if you
wholeheartedly agree or disagree with me.
(ii) BitSet.toString() is incorrect because it does
Hi Danny,
Sorry for the delay in getting back. Overall the changes look great. The
implementation looks correct and the tests look exhaustive. I have a few
high level comments:
(i) Can you refactor some of the code in BitSet.java to make it more
concise? For example, can't you write andNot in
