DEV Community: Hussein Mahdi

this loses money when ___" is brilliant.

Hussein Mahdi — Wed, 07 Oct 2026 23:18:09 +0000

Highlights intuition vs explicit rules

Info Inlet

Oct 3

A junior asked me how I knew the code was wrong. I couldn't answer him.

#discuss #ai #webdev #career

7 min read

New code is upload of new model 🚀🥇

Hussein Mahdi — Thu, 17 Sep 2026 23:12:34 +0000

Hussein Mahdi

Sep 13

Predicting Drug-Drug Interactions with Hypergraphs — on Two CPU Cores

#ai #productivity #architecture #machinelearning

5 min read

Predicting Drug-Drug Interactions with Hypergraphs — on Two CPU Cores

Hussein Mahdi — Sun, 13 Sep 2026 06:04:00 +0000

When a patient takes several medications at once, two of them can interact in ways that cause real harm. DrugBank catalogues 86 distinct mechanisms for how this happens — one drug slowing another's metabolism, increasing its toxicity, blunting its effect, and so on. Screening every pair by hand does not scale.

Most machine learning approaches to this problem split it in two: one model decides whether two drugs interact, a completely separate one decides how. That split is convenient for benchmarking and awkward for anything practical.

We built H²GNN to do both in one hierarchy, using nothing but SMILES strings as input. The code is now public, and the whole thing runs on two CPU cores.

Code: github.com/Hu8MA/HHGNN
Paper: ECAI 2026, IEEE Xplore

Why hypergraphs

In an ordinary graph, an edge joins exactly two nodes. That is a poor fit for a lot of chemistry. A molecular substructure is not a relationship between two drugs — it is something that dozens of drugs share simultaneously. An interaction mechanism is not a property of one pair; it is a category that hundreds of pairs fall into.

A hyperedge can connect any number of nodes at once, which lines up with both of those facts. H²GNN uses two hypergraphs stacked on top of each other.

Stage 1: the chemical hypergraph

Take a SMILES string and slide a window of size k across it. Each window is a substring — a rough proxy for a local chemical arrangement. Every distinct substring becomes a node, and every drug becomes a hyperedge connecting the substrings it contains.

At k = 9, that gives 29,462 substructure nodes, 1,709 drug hyperedges, and 96,656 connections between them.

A single hypergraph attention layer runs over this structure. Attention flows at the hyperedge level, then the node level, and the result is a 128-dimensional embedding per drug learned end to end from raw SMILES. An MLP decoder takes the embeddings of two drugs and predicts whether they interact.

Result: 98.46% ROC-AUC, 93.20% accuracy.

For comparison, a Random Forest on 4,096-dimensional Morgan fingerprints gets 88% ROC-AUC. A two-layer GCN gets 95%.

Stage 2: the interaction-type hypergraph

Here is the part I find most interesting, and it is a small conceptual shift with a large effect.

The obvious way to classify interaction mechanisms is to attach a label to each drug pair and train a classifier. We did something else: each of the 86 interaction types becomes a hyperedge, connecting every drug that participates in that type. Drugs are the nodes. The type stops being a label on the data and becomes an object in the graph with its own learned representation.

This hypergraph is tiny — 1,709 drug nodes, 86 type hyperedges, 13,486 connections. Hyperedge sizes range wildly: type 42 touches 5 drugs, type 49 touches 1,308.

Drug nodes are initialized with the embeddings transferred from Stage 1, not randomly. Attention then flows hyperedge → node → hyperedge, so the type hyperedges — which are the prediction target — end up holding the final aggregated representation.

Result: 85.73% Top-1 and 98.11% Top-3 accuracy across 86 classes.

That twelve-point gap between Top-1 and Top-3 is itself useful. The correct mechanism is almost always among the top three even when it is not ranked first, which is exactly what you want if a clinician is reading the output rather than a downstream script.

The ablations that mattered

Two experiments did more to convince me the design was right than any headline number.

Attention direction. Stage 2's drug nodes start out well-informed, carrying transferred chemical knowledge, while the type hyperedges start from one-hot vectors. So it seemed plausible that flowing attention from the informed side — node → hyperedge → node — would work better.

It does not. It falls apart:

Configuration	Top-1 Acc.	PR-AUC	Macro F1
hyperedge → node → hyperedge	85.73%	87.24	81
node → hyperedge → node	67.42%	63.54	48

Aligning the attention flow with the prediction target beats starting from the richer initialization, and the rare classes are the first thing you lose. The type hyperedge has to be where aggregation ends.

Embedding transfer. Replace the transferred Stage 1 embeddings with an all-ones vector and hold everything else fixed:

Initialization	Top-1 Acc.	PR-AUC	Weighted F1
Stage 1 embeddings	85.73%	87.24	86
All-ones vector	82.52%	85.70	82

A 3.21-point drop. The hierarchy earns its keep.

There is also a third result I did not expect. During cleaning, 406 drug pairs turned out to carry more than one interaction type; we kept the first and set the others aside. The model never saw those secondary labels for those pairs. It surfaced 94.7% of them within its Top-3 predictions anyway — meaning the hypergraph learned something about multi-mechanistic pharmacology rather than memorizing one label per pair.

The efficiency story

This is the part that surprised me most, and it is worth spelling out for anyone who assumes graph learning implies a GPU budget.

Everything above was trained and evaluated on Google Colab's free tier: two vCPUs, no GPU. We chose it deliberately, for two reasons. It gives every run an identical environment, and its resource ceiling is close to the hardware actually available in a hospital pharmacy.

Model	Training time	Hardware
Interaction-Type HGNN (ours, 1 layer)	18.6 min	CPU, 2 cores
GCN (2 layers)	75.6 min	GPU (T4)
GraphSAGE (2 layers)	148.5 min	GPU (T4)
XGBoost	225.6 min	CPU

Four to twelve times faster — and it still beat GraphSAGE, the strongest baseline, by 4.8 points of Top-1 accuracy and 22 points of macro F1.

The baselines had advantages we did not give ourselves: precomputed Morgan fingerprints as input features, and inverse-frequency class weighting during training to stay stable under the severe class imbalance. Single-layer variants of the GCN and GraphSAGE did not converge at all; both had to be deepened and moved to GPU for the comparison to run. A Graph Attention Network never converged and was dropped.

Peak RAM increase during training: 0.29 GB.

What is in the repo

The dataset is DrugBank — 1,709 drugs, 191,877 unique interaction pairs, 86 types, built by merging two benchmark sources so that every drug has a SMILES string.

Everything needed to reproduce the numbers is there:

Colab notebooks for all 48 experiments, with inline outputs
Pre-computed k-mer files for k = 3, 6, 9, 12
Hypergraph structure files and index maps
The exact seeded train/validation/test partitions, verified for zero leakage
Baseline notebooks (GCN, GAT, GraphSAGE, XGBoost, Random Forest)

Open a notebook, point it at the data files, run all cells. Free tier is enough.

What it does not do

Being honest about the boundaries, since these are the interesting problems:

SMILES only. No protein-target, pathway, or side-effect information. Chemical structure carries the entire representation. Additional modalities could enter as further hyperedge families.
No severity prediction. The model reports the mechanism and its likelihood, not how bad the reaction will be — which is often the thing that actually drives a clinical decision.
1,709 drugs. DrugBank now holds over 4,000, so plenty of approved drugs cannot yet be screened.
Pairs only. Real polypharmacy is not pairwise. The hypergraph formulation could express simultaneous multi-drug combinations directly; we just have not done it.

That last one bothers me the most, because the machinery is already there. A hyperedge over three co-administered drugs is a perfectly natural object in this framework.

If any of these interest you, contributions are welcome — there is a contributing guide in the repo, and the issue tracker is open.

Code: github.com/Hu8MA/HHGNN
Paper: Hierarchical Hypergraph Neural Networks for Multi-Type Drug–Drug Interaction Prediction, ECAI 2026, IEEE Xplore

Thanks to the DrugBank Foundation for access to the curated drug data that made the dataset complete.

Who wants to know what the library is in the context of artificial intelligence development?

Hussein Mahdi — Sun, 12 Jul 2026 22:14:04 +0000

Hussein Mahdi

Feb 9

NumPy vs List: SIMD Vector Processing with Concrete Mathematical Example

#webdev #ai #programming #tutorial

4 min read

For anyone interested in learning about the history, concepts, and philosophy of graph neural networks, please refer to this article.

Hussein Mahdi — Thu, 09 Jul 2026 21:32:09 +0000

Hussein Mahdi

Feb 4 '25

Revisiting the 2009 GNN Paper: Foundations (Part 1)

#ai #machinelearning #tutorial #programming

9 min read

The first article in the Panda Library Mastery series

Hussein Mahdi — Tue, 07 Jul 2026 22:08:27 +0000

Hussein Mahdi

Feb 26

Mastering Pandas — Part 1: Reading, Sorting & Displaying Data

#ai #tutorial #python #programming

8 min read

The Leash That Makes AI Polite

Hussein Mahdi — Tue, 09 Jun 2026 07:05:00 +0000

How a 1951 statistics formula quietly keeps your chatbot from going feral

Two ideas sit underneath every modern AI assistant you've ever used. One is a 70-year-old equation. The other is the training trick that turned a text-prediction engine into something you'd actually want to talk to. They're connected — and the connection is more interesting than either alone.

First: measuring surprise

Start with Kullback–Leibler divergence. The name is intimidating; the idea isn't. It measures how different two sets of expectations are.

Picture a weather forecaster. Reality is: 70% sunny, 30% rain. But you wake up convinced it's a coin flip — 50/50 — and dress accordingly. KL divergence is the price you pay, on average, for believing the wrong thing. Get caught in the rain, get overdressed in the sun — small mismatches, small cost. If instead you believed it was always sunny and walked into a downpour, the cost is enormous.

That's the whole concept. Two numbers: how things actually are, and what you assumed. KL puts a single value on the gap.

Three things to remember about it. It's zero only when your belief is perfect. It can climb toward infinity when you're badly wrong. And it's lopsided — being too optimistic and being too pessimistic don't cost the same. It isn't a tidy ruler; it's a penalty for surprise.

Then: teaching taste

Now the second idea. A raw language model is a spectacularly good guesser of the next word, trained on a firehose of internet text. It is not helpful, honest, or polite. It will cheerfully complete a sentence in whatever direction the statistics pull it.

RLHF — Reinforcement Learning from Human Feedback — fixes that. Show humans two answers to the same question, ask which is better, collect thousands of these judgments, and train a second model to predict human taste. Then nudge the language model to chase higher scores from that taste-model. That's how it learns to be useful instead of merely plausible.

Where they meet

Here's the catch. Let a model chase a reward with no restraint, and it cheats. It discovers that flattery scores well, that vague hedging is rarely wrong, that "Great question!" pleases the crowd. Left alone, it drifts into a sycophantic mush — gaming the score while forgetting how to talk.

So engineers attach a leash. At every step they ask: how far has the model drifted from its original self? That distance is measured with KL divergence. Drift a little, fine. Drift too far, and the penalty pulls it back.

The polished, agreeable voice of your favorite chatbot is the product of exactly this tension: a reward pulling it toward what people like, and a 1951 formula tugging the other way, whispering don't go feral.

Which is more important to a data scientist: NumPy or List 🎇? But should they also consider performance 🤔? This article explains. Read it; it will be helpful.

Hussein Mahdi — Sun, 31 May 2026 22:45:56 +0000

Hussein Mahdi

Feb 9

NumPy vs List: SIMD Vector Processing with Concrete Mathematical Example

#webdev #ai #programming #tutorial

4 min read

[Boost]

Hussein Mahdi — Sun, 31 May 2026 12:26:01 +0000

Hussein Mahdi

May 24

The Math Behind Neural Networks — Explained Like Nobody Did for Me 🧨

#ai #machinelearning #datascience #deeplearning

1 min read

What will you think of when you read about a neural network!!? Mathematics? 🤔

Hussein Mahdi — Tue, 26 May 2026 23:18:26 +0000

Hussein Mahdi

May 24

The Math Behind Neural Networks — Explained Like Nobody Did for Me 🧨

#ai #machinelearning #datascience #deeplearning

1 min read

The Math Behind Neural Networks — Explained Like Nobody Did for Me 🧨

Hussein Mahdi — Sun, 24 May 2026 23:09:41 +0000

How does a neural network actually learn to be less wrong?

Not the hand-wavy version. The real one. The one with the derivative, the chain rule, and the loss surface that nobody draws for you when you start.

I got tired of tutorials that skip steps, so I wrote the series I wish I had when I began. No formula without explanation. No "as you can see." No magic.

It is now live on GoPenAI — and I am sharing it here on dev.to for the first time.

Part 1 — Where the math actually begins
Slope → linear regression → error (MSE). One continuous idea, built from the ground up. We stop right at the moment the real question appears: now that we can measure how wrong the model is, how does it learn to be less wrong?
👉 https://blog.gopenai.com/the-math-behind-neural-networks-explained-like-nobody-did-for-me-cda519ef63e8

Part 2 — How the network actually learns

The derivative — slope, but instantaneous
Gradient descent — walking down the loss surface
Multiple layers — how a single neuron becomes a network
Backpropagation — the chain rule, finally demystified 👉 https://blog.gopenai.com/the-math-behind-neural-networks-explained-like-nobody-did-for-me-7db69dc6f1bd

What is the one concept in neural network math that confused you the most when you started? Drop it in the comments — it might become a future chapter.

Building QuizTest — A WPF Quiz Application for Educational Institutions

Hussein Mahdi — Thu, 23 Apr 2026 08:13:00 +0000

Building QuizTest — A WPF Quiz Application for Educational Institutions

I'm excited to share QuizTest, a WPF desktop quiz application I built in C# and which is now actively used at Al-Mustaqbal University. What started as a small tool for a sports-college competition has grown into a flexible platform used by the College of Science's AI Department.

🔗 GitHub: github.com/Hu8MA/QuizeTest

The Problem I Wanted to Solve

Most quiz applications I came across fell into one of two categories: either they were heavy web-based platforms that required internet access and accounts, or they were rigid desktop tools where editing questions meant touching the source code. For classroom use and university events in Iraq, I needed something simpler. Instructors should be able to change questions on the fly without asking a developer, and the app should run offline on any Windows machine.

That's how QuizTest was born.

Tech Stack

The application is built on a deliberately minimal stack. It uses C# with WPF on .NET 6.0 for the desktop UI, and relies on ClosedXML for reading the Excel-based question bank. That's essentially it. No database, no server, no cloud dependency.

From v1.0 to v2.0 — A Lesson in Simplification

Version 1.0 was used in an inter-university competition hosted by the College of Sports at Al-Mustaqbal University, involving multiple Iraqi universities. It worked well, but it relied on Entity Framework and SQLite to store questions. Every time a professor wanted to update the question bank, someone had to edit the database or rebuild the project. It felt heavier than it needed to be.

Version 2.0 rethought the architecture. I removed the database entirely and replaced it with two simple files: Questions.xlsx for the question bank and Settings.txt for configuration. Any instructor can now open the Excel file, edit questions, save, and relaunch the app. No developer required. This version is currently in use by the Department of Artificial Intelligence.

How the Question Bank Works

Questions live in a plain spreadsheet with three columns: Id, Text, and Answer. For example:

Id	Text	Answer
1	Machine learning requires labeled data.	FALSE
2	Python is an interpreted language.	TRUE

The application loads the workbook at startup through QuestionLoader.cs, which uses ClosedXML to parse the rows into a list of question objects. From there, a random subset is selected based on the configured question count, so every quiz session feels fresh even with the same bank.

Version 1.0 was used for the sports department events at Al-Mustaqbal University, while version 2.0 was used for the artificial intelligence department competition events at the same university in 2026.

Configurable Settings Without Recompiling

The Settings.txt file keeps things refreshingly simple:

QuestionCount=20
TimePerQuestion=15

SettingsLoader.cs reads this file at launch and applies the values to the quiz engine. Want a 10-question quiz with 30 seconds per question? Change two numbers and save. This small design decision has made the tool genuinely usable by non-technical staff.

Project Structure

The codebase stays intentionally flat and readable:

Quize/
├── Images/
├── ModelData.cs
├── QuestionLoader.cs
├── SettingsLoader.cs
├── MainWindow.xaml(.cs)
├── QuizWindow.xaml(.cs)
├── ResultWindow.xaml(.cs)
├── Questions.xlsx
└── Settings.txt

Three windows handle the full user flow. MainWindow is the landing screen, QuizWindow runs the timed question-by-question experience with visual indicators, and ResultWindow displays the final score.

Getting Started

If you want to try it yourself, clone the repo and open Quize.sln in Visual Studio. Install the ClosedXML NuGet package, then build and run. You'll need .NET 6.0 or later on a Windows machine. Swap in your own questions by editing Questions.xlsx, and you're ready to go.

git clone https://github.com/Hu8MA/QuizeTest.git

What's Next

I'd like to extend QuizTest with support for multiple-choice questions (the current version handles true/false), a richer result screen with per-question review, and possibly a simple question-editor UI for instructors who prefer not to work in Excel. I'm also considering a lightweight export feature so results can be saved as a report after each session.

Closing Thoughts

QuizTest is a reminder that sometimes the best upgrade is removing complexity rather than adding it. Dropping the database in v2.0 made the app smaller, faster, and dramatically easier for real users to maintain.

If you find the project useful, have ideas for features, or want to contribute, the repository is open and MIT-licensed. Issues and pull requests are very welcome.

👉 Repository: github.com/Hu8MA/QuizeTest

Thanks for reading — I'd love to hear your thoughts in the comments.