Okay, looks like I found the problem. The problem isn't with adjustSize, it's with the bitvector "=" operator. I had the following setup similar to this:
bitvector bitv = "0000000000000000000000000000000000" bitvector bitv2 = "1"; I did a bitv = bitv2 and expected bitv = "1" but it actually was bitv = "0000000000000000000000000000000001" So that screwed up the |= operation further down. The work around I used to solve this was to clear bitv before assigning bitv2. bitv.clear(); bitv = bitv2; now bitv = "1" Not sure if that is the intended usage of "=". Thanks John! Take Care, Teryl On Mon, Mar 19, 2012 at 2:56 PM, Teryl Taylor <[email protected]>wrote: > Hi John, > > So looking into this a little more, it looks like appendFill (used by > adjustSize) pushes the existing bitmap over and fills in the LSBs. So if > I have a bitmap with 1 at the zero element, and I adust the size, to 10, > the 1 gets pushed to over 10. Was this the intended functionality of the > function? I'm looking for something that will leave the 1 in it's same > location and put the zeros on the other side of it. Is there an easy way > to do that? > > Best Regards, > > Teryl > > > On Mon, Mar 19, 2012 at 12:40 PM, Teryl Taylor <[email protected]>wrote: > >> Hi John, >> >> It looks like the adjustSize is the problem. If I call >> adjustsSize(0, 316) on the vector, it prepends the zeros to the front of >> the bitvector instead of appending the zeros to the end of the bitvector. >> >> Is that the intended functionality of adjustSize? >> >> Cheers, >> >> Teryl >> >> >> >> >> On Fri, Mar 16, 2012 at 2:13 PM, K. John Wu <[email protected]> wrote: >> >>> Hi, Teryl, >>> >>> Looks like the code for handling tow bitvectors with differing sizes >>> has some bugs in it. I will look into the problem. In the mean time, >>> simply making sure the two bitvectors represents the same number of >>> bits should give the desired answer. The function to use to make sure >>> the shorter one has the same number of bits as the longer one is >>> ibis::bitvector::adjustSize. This function takes two arguments, it >>> will fill the bitvector with 1s until the position given by the first >>> argument and then fill the remaining positions with 0s until the >>> second argument. >>> >>> Good luck. >>> >>> John >>> >>> PS: The documentation of ibis::bitvector::adjustSize is available >>> online at >>> >>> >>> http://lbl.gov/~kwu/fastbit/doc/html/classibis_1_1bitvector.html#a96d95020682574405a91ac6dfed1da69 >>> >>> >>> >>> On 3/16/12 9:31 AM, Teryl Taylor wrote: >>> > Hi John, >>> > >>> > I hope all is going well! I'm playing around with the >>> > ibis::bitvector API and I'm seeing some peculiar behavior. I'm >>> > trying to AND two bitmaps of different sizes together.... The first >>> > bitmap looks as follows: >>> > >>> > >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > ----------------------------------------------------------- >>> > >>> > This bitvector stores 0 bits of a 1-bit (1 set) sequence in a 0-word >>> > array and one bit in the active word >>> > 0 1 1 2 2 3 >>> > 0123456789012345678901234567890 >>> > ------------------------------- >>> > 40000000 1 >>> > ----------------------------------------------------------- >>> > >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > It has one set bit, and that is the zeroth bit in the bitmap. It is >>> > basically one 32 bit literal. >>> > >>> > >>> > I want to And it with the following bitmap which is 326 bits long >>> > which is basically all 1's. >>> > >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > >>> > This bitvector stores 310 bits of a 326-bit (326 set) sequence in a >>> > 1-word array and 16 bits in the active word >>> > 0 1 1 2 2 3 >>> > 0123456789012345678901234567890 >>> > ------------------------------- >>> > 0 c000000a 310*1 >>> > 7fff8000 1111111111111111 >>> > >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > >>> > Now, the first bitmap, should match with the first bit of the second >>> > bitmap (so, basically the first bitmap should be seen as 326 bits >>> > long...with the first bit being set to 1, and the rest zeros). So >>> > when I AND the two together, I want the result to be a bitvector with >>> > the first bit set to one, and the following 325 bits all set to zero. >>> > >>> > >>> > But what I'm seeing is the following result: >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > >>> > This bitvector stores 310 bits of a 326-bit (1 set) sequence in a >>> > 1-word array and 16 bits in the active word >>> > 0 1 1 2 2 3 >>> > 0123456789012345678901234567890 >>> > ------------------------------- >>> > 0 8000000a 310*0 >>> > 40000000 1000000000000000 >>> > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > Which has 310 0's before the one bit is set.... I'm using the &= >>> > operator to do operation. so it goes smallBitmap &= bigBitmap. >>> > >>> > >>> > Is there an easy way to get the answer I am looking for? Or am I >>> > using the bitvectors incorrectly? >>> > >>> > >>> > Best Regards, >>> > >>> > >>> > Teryl >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > FastBit-users mailing list >>> > [email protected] >>> > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >>> >> >> >
_______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
