Background

Over the past 8ish years, I’ve been working professionally across various aspects of drug discovery. Early on in my career, I focussed a lot on applying chemoinformatics techniques to make natural product discovery more effective. In my current role, we’re developing strategies to make data more discoverable and accessible using LLMs within clinical trial operations. As I started to dig into one of the more common techniques for this, retrieval augmented generation (RAG), I began to see a ton of similarities to how we used to search for chemical structures.

Both of these techniques rely on the core concept of vectorizing a complex input, storing this information in a specialized database and then doing simple distance measurements. These are demonstrated in the workflow images depicted below.

Similarities between the two workflows

At a high level, there are several thematic similarities between the two workflows. First, an embedding model (or algorithm) is used to ingest a complex input and translate it into a simplified representation that can then be indexed. Second, a similarity search is conducted using a relatively simple distance measure. These distance measures can be performed using highly optimized vector databases.

In both workflows, an indexing and querying pipeline is required to ingest and index data into a database prior to individual user queries.

Differences

Chemicals vs unstructured text

Abstract unstructured text is far more complex and unpredictable than the typical kinds of organic chemical structures that are usually queried in drug discovery.

Chemical structures are often stored in a text-based format called SMILES. Over the past decade, there has been significant research on leveraging advances in language models to ingest and generate novel chemical entities, known as generative chemistry. Unlike unstructured text that may provide narrative stories over long context windows, chemical structures have a fixed length with the majority of drug-like molecules containing fewer than 1,000 tokens. Drug like molecules also only have a small number of letters (atoms) have to follow a set of chemical rules (e.g. max number of bonds per atom) that limit the overall complexity of the data structure.

Working with simpler data structures meant that we were able to use simpler encoding methods (see more below).

Embedding models vs hashing algorithms

Embedding models for text are trained on large amounts of text data to better group text-based concepts. In the past, strategies like word2vec were used to convert words into vectors that retained some degree of sematic understanding. Today, embedding models are much more sophisticated than this and can relate abstract concepts not only across words but across varying lengths of multi-lingual text.

In the chemistry side, the most popular embedding strategy was something called the circular fingerprint. Here, individual atoms were profiled according to their surrounding environment to generate a unique hash. This hash was then converted to a number between 0-1023 using a bloom filter to generate a fixed-length binary vector.

This is not a perfect difference, simpler strategies (like word2vec) were used in NLP while more complex ML based systems have been employed and are continuously being iterated upon in the chemoinformatics domain.

Vector databases

At the time, for most of my research career, chemical similarity searches were done in a Python script where I performed a nested for-loop to compare my set of query molecules to everything in our database. However, when building more end-user focussed systems, I have used the RDKit Postgres cartridge to simplify molecule indexing and similarity searches.

Today however, there are so many vector databases to choose from that support vector indexing and distance based queries out of the box. Tools like ChromaDB as well as extensions for common databases like Elasticsearch and Postgres allow for RAG-based agents to be built very easily as extensions on top of existing databases. The open-source community and tools for LLMs are much more developed (not surprising given the recent LLM hype), but this could definitely help if I try my hand out at some chemoinformatics again soon!

One of the biggest challenges for building chemical databases wasn’t necessarily the chemical structures themselves but handling all of the unstructured metadata that accompanied each entity. It almost makes me wonder if we could build a better chemical database using LLMs to embed and contextualize molecular properties currently stored in text form.

If you like more content like this, let me know! Reach out on LinkedIn or leave a comment below.

As a result of commuting, I’ve found myself back playing mobile phone and web games on the train. It’s a nice pass time, but I recently came around a game that although seems remarkably simple, it’s actually a ton of fun to play (plus it gets really challenging). Handulum + is a physics based game where you can “catch” a falling ball and swing it along a pendulum. I got decently far, but wanted to see what it would take to actually recreate this sort of physics engine. I’m not really a game developer, but I’ve been really interested in developing more low level graphics for creative side projects and though this would be a good place to start. Check out Handulum + below though, its miles beyond anything I could create!

The first thing I did was choose my ecosystem. Since my day job mostly revolves around Python, I quickly found myself reading into PyGame. The syntax was brief enough and it could draw circles and lines, which was more than enough on the graphics side for me. My main goal here was to recreate the physics involved, not spend too much time trying to make it pretty (although that might be a fun extension to this project). A few tutorials later, I now had a bouncing ball that somewhat emulated gravity.

But this game obviously required a bit more than bouncing. I needed to figure out how to get the ball to move in circle, and even more, observe some conservation of momentum as it attached and released from the pendulum. This was certainly more challenging than I had initially thought, and quickly found myself lost in Google searches and endless equations describing motion in “simple” pendulums (not so simple for me!).

When I first started, I simply tried to do everything via code, but I quickly found the ball moving in all sorts of crazy ways, and not getting and progress. In the end, I found it best to just draw it out, and pull out some handy-dandy trigonometry. What’s not shown below are the 10+ other pages of scribbles that I threw away along the process.

I realized were two key aspects that I had to consider:

• Converting forces in x and y directions to an angular direction via trigonometry (thanks to SOH-CAH-TOA).
• Understanding that angular velocity can be represented as linear velocity (in x and y direction) via the angle of the tangent, which luckily enough is also calculable via trigonometric equations.

Overall, this took me quite a bit longer than I expected, but I did end up learning a lot and brushing up on some mathematics that I had long forgotten. Doing this in Python made this project a lot easier as I was very comfortable code organization and structuring everything in an object oriented manner. Take a look at the prototype below:

If you’re even more curious, feel free to fork the repo and try running it yourself. Let me know what you think.

Repo: HandBall

Who doesn’t love XKCD? A while back, around the start of my grad school, I came across a relevant machine learning comic from Randall (see below). Today, we’re going to throw some NLP and topic modeling into a pile and hope something fun comes out the other end.

First things first, lets download some of these comics. Altogether, Randall Munroe (author of XKCD) has been extremely productive and has created over 2100 comics since the inception of XKCD on January 1st 2006! Looking at this, he is scarily consistent, averaging about 13 comics a month. The first month is an outlier, I imagine he had a butt load of comics he had drawn and released them all onto the internet at once. But I truly admire his consistency!

Next, lets gather some more data. Thankfully, the folks at Explained XKCD have annotated each of these comics with a transcript as well as their own explanations for each. This, along with the actual images, meant I had a rich dataset to work with of roughly unstructured text and their corresponding comics.

We have data, now what?

The title of this section accurately describes how I felt at this stage in the project. With work, I usually have a goal or end project, but I wanted to use this dataset to learn some new skills. So, I thought to try a bit of topic modelling. I really like this technique because it essentially allows the data to “self-organize”! Basically, based on the co-occurance of specific words, we can identify several topics that are commonly used in XKCD comics. After surprisingly little actual coding, I was able to build a Latent Ditrecht Allocation (LDA) model that identified 10 topics of interest.

Creating the model itself was pretty simple:

1. Lemmatizing all words identified in both transcript and explanations of the comic. Gensim / NLTK libraries helped out a lot here!
2. Create a dictionary, and remove all words that appear relatively infrequently.
3. Use gensim to build an LDA model across 10 topics, passing over the data 20 times.

And with that, we get the following topics revealed.

Looking through some of these, there were some that were surprisingly accurate. For example, barrels is a recurring theme in his works, and was deserving of a whole topic on its own. Other topics such as 2, 5, 6 and 9 were very rarely observed.

Lets search by topic!

From here, I started playing around to see how we could sort and search for these topics among all of these comics. In particular, I wanted to share this with all of you. So, using the LDA model for each of these topics, I wanted to create a web app with SLIDERS! Realistically, you can use the sliders to identify the mix of these topics you want, and with my website, I’ll identify the top five comics that match your search. Kinda like the DJ booth of XKCD comics!

I built this pretty rapidly using Flask to act as the backend + server side rendering engine. Heroku allows you to deploy flask applications with ease, and for free so you can find it all on there.

• WebApp
• WebApp Source code
• GitHub code for this analysis

Overall, I was pretty impressed with this dataset. In the end, I wanted to put something out before diving too much into the data science-y aspects of it, as I could have diven much deeper! For anyone curious, here are a few more ideas I had / might pursure with this dataset:

• Sentiment analysis (How positive / negative / angry do each of the comics read?)
• Image analysis using deep learning
  • Can we cluster according to these topics that we identified?
• How many topics is ideal? What words are most common?
• With StyleGAN out there now, can we generate some of these drawings of Megan / beret man?

I recently came across Storytelling With Data, and their #SWDChallenge. Sad that I missed their last round, I was quick to jump on this month’s challenge. The challenge this month was to revamp this figure depicting the change in global travel markets from 2000 to 2016.

The first thing I saw with this chart is the title, and I had absolutely no idea what APAC was. Only after playing with the data for a while, I realized that APAC=Asia Pacific, and that in 2016, this region has the largest share of the travel tourism market. While great to include a clear takeaway in a figure, it was lost in translation. Next, I realized that my eyes were constantly bouncing between the two pie charts, more so comparing the percentage values than the actual size of the pie (pie charts are notoriously difficult to interpret) So, moving forward, I knew I had to fix a few things:

1. Use consistent acronyms across the chart.
2. Provide a way for data to be directly compared, without the use of pie charts.

With these two goals in mind, I created a new interpretation of this data set:

This plot was created with matplotlib, with slight modifications using inkscape (mainly for the legend). One aspect I wanted to highlight in this graph is the difference between 2000 and 2016, which is why I chose to emphasize this with arrows, coloured according to the direction. Only after I plotted this data, I could appreciate that Asia Pacific is not only the largest travel market, but also that all other regions have lost lots of this market share.

All of the code needed to plot this is hosted on my GitHub. Feel free to peruse and suggest any improvements!

This past weekend, I participated in DeltaHacks IV at McMaster, and got a chance to meet, learn and collaborate with a lot of awesome people. Our team decided to tackle one of the challenges posted, to improve workplace safety. Our idea was to create an object recognition mobile application that employees could use to easily identify the dangers and safety protocols required to operate the equipment around them.

Together with Ryan and Sujan, we built SafetyFirst.

The technology

A lot of this app was made possible through the work done by Google’s research team. In 2017, their team released several object recognition models trained on the COCO dataset. While they all work well, we chose to use the “Single Shot Multibox Detector (SSD) with MobileNet” due to its rapid prediction time. After trying a few others, we found that this model could provide reliable results in seconds running on just a CPU.

To use this model, we built a simple webserver using Flask to expose a single endpoint. This endpoint, when deployed receives images base64 encoded and embedded within a JSON object. At this point, the image is decoded in the backend and sent through the network for classification, and bounding box prediction. Using PIL, the bounding boxes of each prediction are drawn on the image before sending it back to the user, along with prediction data. To deploy this application, we used Heroku. Although I had never used it before, it’s surprisingly simple to expose a Flask application through there.

The front end of this application was built using Android Studio. This was entirely built by Sujan, and he did an amazing job. This app currently allows users to take pictures, send it to the webserver for prediction, and then display the results. For each of our predictions, Ryan setup a MongoDB document collection that was exposed through a RESTful API. MongoDB was another tool that I had just learned about, and was impressed with how easy and quick it was to setup.

Feel free to poke around or fork our git repo. Happy hacking!

Acknowledgements

A big thanks to DeltaHacks IV organizing committee, your hard work made all of this possible. Another thank you to AccelorMital Dofasco for awarding us with the Workplace Safety prize. And finally a thanks to all the judges that deemed us worthy as one of the top six finalists.

Hi all! Welcome to my blog. As you might already know, I’m currently heading towards the end of my graduate career and thought about all of the things I’ve learned through my time here. To keep some record of it and share a few of my experiences, I’m publishing some tidbits of knowledge here. Keep posted, and while I have you, I’ll show you a neat little trick I use daily.

jless

I use the JSON format almost everywhere, and it provides a simple medium to transfer data interplatform, and is readable by almost anything. On the CLI, I use jq to view this. To make this even easier, I use the jless CLI command, which makes this process much more unix-esque.

Insert this into your .zshrc or .bashrc and your good to go!

jless() { jq . $1 -C | less -R; }