http://www.perlmonks.org?node_id=733910

in reply to Compact and sparse bit vector

The only thing is a lot of the time people use vec() specifically because they want the string to be a bit-vector. They dont want to use it as an array of <8 bit units of information so much, as a way to individually control bits in a string with a reasonably syntax.

Although having said that, the problem with vec() in this form is that it doesnt use native byte order, so you cant normally pass it directly into a C routine. So i guess your proposal has some merit...

---
\$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^2: Compact and sparse bit vector
by BrowserUk (Pope) on Jan 03, 2009 at 10:00 UTC

Actually, the main use for bitvectors in the NetFlix challenge. is that you can do very fast relational math.

So performing the select to find all the people who have rated all the same movies (and the movie we are trying to generate a rating for), that we already have a rating for by the person we are trying to generate a rating for, is just a tight loop over the dataset performing bitstring boolean operations which are very fast (in perl).

Doing the same operations (AND/OR/XOR/etc. of every bit of one bitstring against every bit of another bitstring for every customer in the DB) using Judy arrays, would not benefit at all from any of their special properties (cache line locality), and be extremely slow.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

I've never really found myself doing vector operations of bitmaps against each other. I didn't notice that being a feature of the linked Netflix node. I do occasionally find it convenient to have a sparse bitmask. Usually I just use a hash of the stringified integer.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

There's no implied criticism of Judy arrays, or your module, for the uses for which they are designed.

And indeed, there is no requirement in the NetFlix challenge to use bitvectors at all. There is a need however, to perform some more or less complex relational operations across the three datasets to arrive at the goal of the challenge: To estimate a user rating for given user for a given film (that they haven't yet watched or rated) based upon how others that have watched and rated the given film have rated it.

Whilst this kind of query is relatively trivial to code using SQL, the volumes of raw data, and size of the cross-product of the film & user bases is such that it is time&memory intensive to produce the results. Using bitwise storage for this type of join query is extremely fast. Some literature.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Heh, I kind zeroed in on the expression "was a sparse bit vector which might be interesting as a replacement for vec()", and didnt even notice the netflix reference. :-)

---
\$world=~s/war/peace/g