rtvp-

I've been reading your post and looking at the 54 bit fingerprint you mentioned. I was wondering if you could help clear up any confusion on my end; I am not sure if I am implementing and applying it correctly.

Regarding the 54 bit fingerprint, if I do a substructure match between a target molecule and the query molecule: "O", and I find there are 3 matches, then if the list of the patterns were:

"0 2 times O largest 55458" and then later "16 3 times O largest 653" "17 1 times O largest 466"

does that mean I should set bit 0, 16, and 17 to 1?

If I've understood correctly up to this point, I would have some additional questions, but if I am totally off, my additional questions would not make sense.

Edit: I had a mistake in my logic with the second question. Removed it

I think I'm getting it now... If I'm going to put a prefix, I could use something that gets more elimination power out of those bytes than what I'm currently using. Do I have the right understanding?

I hadn't even thought of using the prefix for substructure queries, but that is an interesting idea.

Thank you for the links and the new ideas! You've given me a few new ideas to explore

Following up: The average size of the binary molecule in chembl33 is 454.9 bytes

Thank you for the feedback dalke!

Yes, I store those pre-computed values as a header in front of the standard RDKit binary molecule, not the SMILES string.

I first convert the SMILES string to a RDKit molecule. Then I get those values (number of atoms, number of rings, etc.) from the RDKit molecule object. Then I serialize those values as a header in front of the rest of the binary molecule object. Like so: Pre-computed values header (20 bytes) + binary RDKit molecule object (n bytes)

I wanted to store the binary molecule object in my database so that other functionality like substructure searches, or converting to a different molecule format could use that molecule object, like the RDKit Postgres extension `mol` type. But, a separate, dedicated column containing a hash just for exact searches might be even faster with duckdb's string capabilities.

Although a SMILES string may be 60 bytes on average, the binary molecule from RDkit may be bigger. I took a look at chembl, and although it may contain some strange structures, I found that the minimum byte length of a pickled/binary molecule via the RDKit Postgres extension is 65 bytes, with the max being 15,762 bytes [1]. But, I did not calculate the average size of the binary molecule, and your comment helped me to realize that. I should take a look at that. If the average is much bigger, 20 bytes is, perhaps, not too much more overhead.

I am assuming that getting these header/prefix values (number of atoms, rings, etc) from the RDKit molecule is not too expensive. Since the more expensive part of parsing the input (SMILES) and converting it to the RDKit molecule is being done anyways (in order to get the molecule object), I'm assuming I can get those header values without much additional computational cost.

[1]: https://bodowd.github.io/2024/06/18/chembl-column-properties