As suggested by Amit, I am emailing my patch for an implementation of
BitSet. Following the format of Amit's previous message to the group,
I've posted this patch for review at:
http://gwt-code-reviews.appspot.com/33815
I apologize if this separate upload causes redundant email for anyone.
My i
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
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 refactor
> 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
refacto
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
I wrote two versions, one as Amit suggested with getWordPositions, and
one with nextSetWord. The test unit (not counting hash and
constructor tests) for the getWordPosition version was about 45%
slower, while the nextSetWord version was only 37% slower. Both of
these are a rather heavy penalty,
