Re: BitSet.[x]or does (not) grow BitSet

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2002-04-01 at 02:16, Eric Blake wrote:
> Mark Wielaard wrote:
> > 
> > Although the API documentation is not very clear I am inclined to go
> > with the assumption that the BitSet does not grow. So I would like to
> > check in the following to at least make both tests behave the same.
> 
> I question your interpretation. The 1.4 docs state in the class
> description:
> 
> "This class implements a vector of bits that grows as needed... Note
> that the size is related to the implementation of a bit set, so it may
> change with implementation. "

The first sentence might be interpreted that this happens always, but
the language of BitSet.or() and BitSet.xor() does not convince me
immediatly.

That last part is irrelevant since it talks about the size, an
implementation aspect of a BitSet and not about the length.

> > Any objections?
> 
> Your patch does nothing, as the equals() method does not take size into
> account, so it does not matter whether b2 grew or not.

BitSet.equals() does indeed not take size into account since it is
defined in terms of BitSet.set(). But the test is not about equals but
about if a.or(b) takes bits of b into account that are not set/cleared
in a.

> Instead, you
> should patch AcuniaBitSetTest, because it is making blatant assumptions
> about the size of a bit set which do not have to be true, according to
> the specs I quoted.

I don't mind changing one or the other as long as they agree on the
result.

The problem with my original statement was that it talked about growing
the BitSet which is not actually what these tests check. What they check
is the following:

- Given
  BitSet a = {1,2,3}
  BitSet b = {3,4,5}
  BitSet c = a.xor(b);
- Is the result
  - c = {1,2}
  since bits 4 and 5 were not explicitly set or cleared in a.
or
  - c = {1,2,4,5}
  since bits 3 and 5 are set in b.

The language of BitSet.or() and BitSet.xor() is not clear to me about
this issue. I arbitrarily took the interpretation of the first test. But
since you recently rewrote the BitSet implementation for Classpath I am
easily convinced that it should be the other way around :)

Cheers,

Mark