Hi, Teryl, Thanks for your patience. I imagine that you have a small test program that demonstrate this little problem. Would you mind sharing it with us? It would save me some trouble of recreate it.
Thanks. John On 3/19/12 1:19 PM, Teryl Taylor wrote: > 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] > <mailto:[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] <mailto:[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] > <mailto:[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 > > <http://lbl.gov/%7Ekwu/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] > <mailto:[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
