I'm playing with the "Create Bit Vector" node and i'm very confused by the renderers.
I've defined an input table with 6 columns, all of them containing 0 or 1 and some missing values.
The two "Create Bit Vector" nodes are doing the same thing, that is using a 0,5 treshold for all the 6 columns.
The most right column "BitVector display" shows the default display of the bit vector
the next to last column shows the "Set bits" renderer.
As you can see below (click on the screenshot link) , the "Set bits" rendering in OK (indexes of the "1" columns are in the proper order)
But the "BitVector display" rendering is in the reverse order of the columns. If you read the columns EP1_HIGH, EP1_MEDIUM, EP1_LOW, COL3,COL2 and COL1 in this order, then the display is OK.
The other renderer Bit scratch is also in the reverse order.
Is that expected (if so, it's really confusing) or am I missing something?
Endianness may help explain what is going on here.
The BitVector is stored in big endian form where the most signficant byte is stored at the smallest address space. So in your example bit 5 (as we count from 0) is stored at the first position and appears as the first line in the bitscratch or the first 1 on the BitVector display. When you view it in the form where it lists the set bits it is showing you the set bits in numeric order which is why the 5 is last.
If you expand the BitVector back out the set columns will be in the correct order.
This is really the way my brain thinks though so I was also confused the first time I came across this.
Be wary of the fingerprints expander node from the Erl Wood plugins, I think it reverses the BitVector.
Well, it it no less a fingerprint than if the graphic was rendered the other way round. Bit 1 is stil Bit 1 regardless of whether it is little endian and big endian. A problem only occurs if you treat one like the other. As you can see when looking at the list of set bits the numbers are correct.
So you can for example have an atom centred fingerprint stored as a BitVector and use it in various cheminformatic techniques.
I've just checked with the version available in 2 10 stable release and the node does indeed reverse the fingerprint (which it shouldn't do!). So if you want to expand out the BitVector to columns make sure you use the "Expand Bit Vector" node.
Looking at the code what has happens is the fingerprint string is represented in the big endian way but the output columns are little endian (so a conversion has happened).