[jira] [Commented] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits

["Shai Erera (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792338#comment-13792338 ] 

Shai Erera commented on LUCENE-5272:
------------------------------------

After fixing the bug, I realized that the API of OBS is somewhat broken:

* setBits lets you set a {{long[] bits}}, but doesn't modify neither numBits nor wlen.
** Nothing uses this method, so I'll nuke it. There's a ctor for that, so I don't see the advantage.

* setNumWords has the same issues
** Nuke it too, one can call {{new OpenBitSet(other.getBits(), newNumWords)}}.

* get and fastGet don't work the same. If you create OBS(3) and call get/fastGet(5) the result is different:
** fastGet trips the assertion
** get returns false
I'm not sure if get is wrong since if OBS allows growing, it's technically correct to return false. But then, should it change numBits (because now the app effectively 'grew' the array)? If it doesn't, then stupid code like {{get(5); fastSet(5);}} fails because numBits isn't modified...
I don't know if we should fix it because then get() becomes an API which modifies the OBS instance (which is unexpected).

Maybe we should get rid of numBits in OBS entirely? If someone called ensureCapacity(5) and does set/fastSet(17), maybe it's ok if we sometimes succeed in both? set() will grow the bits if needed, fastSet will trip an AIOOBE which is OK I think .. if you want to use fastSet, make sure you call ensureCapacity before.

In the meanwhile, I've discovered I can grow a FixedBitSet very easily by allocating a new FBS instance, and FBS doesn't suffer from these inconsistencies, so maybe I'll just use it for now to make progress, but would still like to resolve the issues raised here.

One possible solution is to offer a convenient ctor to FBS, like FixedBitSet(FixedBitSet other, int numBits) which will arraycopy the bits from other. The only thing we add here is the FBS object allocation, vs OBS which only grows the internal array, but I think that's not critical. If we do that, then we can get rid of OBS entirely I think ... or remove all the fastXXX methods and make it more like GrowableBitSet.

> OpenBitSet.ensureCapacity does not modify numBits
> -------------------------------------------------
>
>                 Key: LUCENE-5272
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5272
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/index
>            Reporter: Shai Erera
>
> It's a simple bug, reproduced by this simple test:
> {code}
>   public void testEnsureCapacity() {
>     OpenBitSet bits = new OpenBitSet(1);
>     bits.fastSet(0);
>     bits.ensureCapacity(5); // make room for more bits
>     bits.fastSet(2);
>   }
> {code}
> The problem is that {{numBits}} which is used only for assrets isn't modified by ensureCapacity and so the next fastSet trips the assert. I guess we should also fix ensureCapacityWords and test it too.
> I may not be able to fix this until Sunday though, so if anyone wants to fix it before (maybe it can make it into 4.5.1), feel free.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org