DEV Community: Vivek Vohra

How I Hosted My First Production Site for ₹0: AWS + Cloudflare Setup

Vivek Vohra — Fri, 03 Apr 2026 14:09:40 +0000

Running a project on localhost is straightforward. But the moment you try to deploy something real : with a custom domain, HTTPS, and a scalable architecture ,you realize how many moving parts are actually involved.

For my project IPlusFlow (an EEG-based Alzheimer’s detection platform), I needed a setup that was secure, scalable, and mirrored real industry architecture. Most importantly, I wanted to run it entirely for free.

Project Links:

🌍 Live Site: eeg.iplusflow.com
💻 GitHub Repository: EEG-CNN-BiLSTM

This is a breakdown of how I wired AWS and Cloudflare together, the architectural decisions I made, and the debugging lessons I learned along the way.

The Architecture Strategy

The goal was to build a production-style design that strictly separated storage, compute, and traffic routing. Putting everything in one place is easier, but separating concerns scales better.

Backend: FastAPI running on AWS Lambda via API Gateway
Frontend: Static files hosted on Amazon S3
CDN: AWS CloudFront
DNS & Edge: Cloudflare

Bypassing Fixed Costs

The standard AWS approach for DNS management is Route 53. It works seamlessly, but it introduces a fixed monthly cost. To keep my infrastructure at exactly ₹0, I bypassed Route 53 entirely and handled DNS through Cloudflare.

I purchased the domain, pointed the nameservers to Cloudflare, and managed all routing for subdomains like eeg.iplusflow.com and api.iplusflow.com from there. It was a simple architectural decision, but it was the most impactful step in eliminating recurring overhead.

Challenges and Learnings

1. The AWS SSL Region Trap

Because my backend was deployed in the Mumbai region (ap-south-1), I generated a wildcard certificate (*.iplusflow.com) there. It attached to the API Gateway perfectly.

However, when I tried to attach the same certificate to CloudFront for the frontend, it simply didn't appear in the dropdown. After digging through the documentation, I learned that CloudFront strictly requires certificates to be generated in us-east-1 (N. Virginia), regardless of where your actual infrastructure lives. I had to provision a duplicate certificate in us-east-1 specifically for the CDN. It is a strict AWS requirement that isn't immediately obvious when you start.

2. The Cloudflare Proxy Conflict

When adding CNAME records in Cloudflare, I initially left the proxy setting enabled (the "orange cloud"). This immediately resulted in SSL handshake failures between Cloudflare and AWS.

In hindsight, the reason was clear: API Gateway and CloudFront were already terminating HTTPS using their own AWS ACM certificates. Cloudflare was attempting to sit in the middle and re-handle the SSL, creating a conflict. The fix was to switch those DNS records to "DNS Only" (the "grey cloud"). Once the proxy was disabled, the handshake issues were resolved.

3. Cross-Origin (CORS) Blocks on Subdomains

My frontend (eeg.iplusflow.com) was designed to fetch presigned URLs from the backend (api.iplusflow.com) to upload EEG files directly to S3. The API responded perfectly, but the browser blocked the actual file uploads.

The issue was CORS. Browsers treat different subdomains as entirely different origins. To fix this, I had to explicitly update the S3 bucket's CORS configuration to allow Origin: https://eeg.iplusflow.com and restrict the method to PUT. After applying that specific policy, the client-side uploads worked.

Why Use Both Cloudflare and CloudFront?

It might seem redundant to use CloudFront when Cloudflare already provides CDN capabilities. I considered dropping CloudFront, but keeping it solved two critical architectural problems:

S3 Security: Without CloudFront, the S3 bucket would have to be public to serve the frontend files. By using CloudFront, I could keep the bucket entirely private, restricting access exclusively through the CDN via Origin Access Control (OAC).
SSL Compatibility: CloudFront integrates flawlessly with AWS certificates. Trying to route Cloudflare directly to a private S3 bucket often introduces complex SSL and routing headaches.

The final flow cleanly separated responsibilities: Cloudflare handles DNS, CloudFront securely fetches from S3, and the S3 bucket remains locked down.

Final Thoughts

This setup achieved exactly what I needed: a zero-cost infrastructure, HTTPS across both frontend and backend, and a clean separation of layers.

More than just getting a project live, this process forced me to understand the lifecycle of a web request i.e. how DNS resolves, where SSL terminates, and how CDNs interact with private storage. If you are deploying your first serious project, I highly recommend skipping the one-click hosting platforms and trying a manual setup like this. It takes more effort, but the technical understanding you walk away with is invaluable.

If you are building something similar and hit a wall, feel free to reach out. I am still learning this myself, and documenting the process is part of that journey.

iPlusCode - a small Chrome extension to make Codeforces a bit nicer

Vivek Vohra — Sat, 01 Nov 2025 20:57:48 +0000

iPlusCode - Bringing Peer Learning to Codeforces Practice

I spend a lot of time on Codeforces, and one thing I always wanted was:
“show me how my friends solved this exact problem, right here, without leaving the page.”

So I built iPlusCode — a Chrome extension that sits on Codeforces pages and adds some extra tools for practice.

In this post, I’ll share what the extension does, how it works (especially the “Friend's code” feature), and some lessons I learned building it.

What it does

Bookmark problems from Codeforces
Add notes to a problem (saved in Chrome sync)
Filter/sort problems by rating or tags
Sync solved problems using the Codeforces API
Hide tags if you don’t want spoilers
Main thing: view friends’ accepted codes in a modal on the same page.

👥 Friends Solutions – Learning from Peers

One unique aspect of competitive programming is learning from others.
I often found myself checking how a friend solved a problem after a contest.
iPlusCode makes this easier by integrating friend's solutions right into the problem page.

When you click “Show Codes” under Friends Accepted Codes, the extension fetches the latest accepted submission for that problem from each of your Codeforces friends (up to a limit).
It then opens a neat modal dialog on the page, showing each friend’s username and their code solution, with syntax highlighting and line numbers.
You can scroll through and see how different people approached the same task - without leaving the page or manually searching on Codeforces.

🔎 How does it know who my friends are?

If you’re logged into Codeforces, the extension can retrieve your friend list.
On setup, iPlusCode scrapes your /friends page (using your session cookies) to get all the handles in your “My Friends” list.
It stores this list (up to 20 friends) in Chrome Sync storage as cf_friends.

⚙️ How does it fetch the code?

iPlusCode uses a mix of the official API and careful HTML parsing:

For each friend, it first calls:

   https://codeforces.com/api/contest.status?contestId=...&handle=...

This checks if the friend has an accepted submission (“OK”) for the current problem.

If nothing found, it falls back to:

   https://codeforces.com/api/user.status?handle=...&from=1&count=1000

Once it finds the submission ID, the extension fetches the submission page directly - the same one you’d see by clicking “View Submission” on Codeforces.
It parses out the code text from the page’s DOM and displays it in a modal using Google Prettify for syntax highlighting.

Behind the scenes, iPlusCode fetches only when you click, not on every page load - and for good reason.

🧠 Lessons Learned

When I first implemented this feature, I thought:
“What if the extension automatically pre-fetches my friend's solutions in the background every time I open a problem page?”

Sounds nice, right? No waiting when you click “Show Codes.”
Well… it didn’t go as planned.

During early testing, Codeforces started showing unusual activity warnings.
Even with a 10-second retry delay, the auto-fetch system looked like a crawler.
Eventually, it triggered anti-bot protection, and I got a temporary suspension 😅.

That was the point I realized: don’t crawl Codeforces automatically.
Here’s what I changed and learned:

✅ Takeaway 1: Use on-demand fetching

Now, iPlusCode fetches data only when you click “Show Codes.”
No background scraping.
It respects Codeforces’ rate limits and makes fewer, intentional requests.

✅ Takeaway 2: Throttle and limit requests

Even on-demand, I limited it to about 20 friends and added a short delay (sleep(700)) between each fetch.
This keeps it human-like, avoids spamming, and still feels smooth for the user.

✅ Takeaway 3: Cache results

After fetching, iPlusCode caches the results for about 10 minutes in Chrome Sync:

friendCache[problemKey] = { timestamp, results }

If you click again within that time, it just shows cached data instead of hitting the API again.

✅ Takeaway 4: Be careful with HTML parsing

Codeforces doesn’t have APIs for everything (like friends list or raw code),
so I had to rely on parsing the page.
I made sure to only read specific elements (like the “My Friends” table) and handle missing cases gracefully.
That way, even if Codeforces changes its layout slightly, the extension won’t break completely.

✅ Takeaway 5: Chrome Extension quirks

This was built using Manifest V3, so I used:

chrome.storage.sync for saving data
secure DOM creation (no direct HTML injection)
fetch(..., { credentials: 'include' }) to use the logged-in Codeforces session That last trick let the extension access private data (like submissions) without needing API keys.

🧩 Wrapping Up

Building iPlusCode was a rewarding project that enhanced my own practice on Codeforces.
Now I can:

Bookmark problems I want to revisit
Keep track of what I’ve solved
Take notes for future reference
Peek at how my friends solved the same problem

Now,I can see different coding styles and ideas instantly - it’s like learning from friends without leaving the page.

If you’d like to try it:

🔗 Chrome Web Store – iPlusCode
💻 GitHub Repository

I’m open to feedback and ideas for new features.
Hope this helps make your Codeforces journey more organized and fun.
Happy coding!

Deploying a CNN-BiLSTM Model on AWS Lambda

Vivek Vohra — Thu, 18 Sep 2025 13:23:19 +0000

Deploying a CNN-BiLSTM Model on AWS Lambda

Deploying my deep learning model to production sounded straightforward at first. I had a Convolutional Neural Network + Bidirectional LSTM (CNN-BiLSTM) model for EEG-based Alzheimer’s detection, and I wanted to expose it via a serverless API on AWS.
But doing so leads to a series of mistakes, and in this post, I try to document the mistakes I made, for my future self and those who might be trying it for the first time and are stuck.

Overview

Before going into the mistakes, let’s briefly discuss the deep learning model. It combines CNN and BiLSTM for Alzheimers’ detection based on EEG data.

Now this app lets users upload EEG .set files and get an Alzheimers’, Frontotemporal dementia, and Healthy prediction with a confidence score. Uploaded files go directly to S3, and then a serverless Lambda (containerized with TensorFlow + MNE) pulls that file, preprocesses it, runs inference, and returns JSON to the browser.

High-Level Architecture

The user uploads the EEG file to the browser.
A presigned URL is issued so the browser can upload directly to S3.
The browser uploads the file to S3 (no server is in the middle).
Browser calls /predict, passing the S3 object key.
Lambda (Dockerized TF + MNE) downloads, preprocesses, and infers.
JSON response returns: { predicted_class, confidence }.

AWS setup (essentials)

S3 bucket: Private; CORS enabled for the frontend domain; object PUT via presigned URLs.
IAM: Execution role for Lambda with S3 read (and PutObject for generating presigned URLs).
ECR: Push the container image (TensorFlow + MNE + model).
Lambda (container): Adequate memory (e.g., 2–4 GB+), timeout (e.g., 120s+), env var for BUCKET name.
API Gateway or Lambda Function URL: Public HTTPS endpoint with CORS enabled.

What is a Presigned URL?

Now, before moving on, what exactly is a presigned URL?

So, an S3 presigned URL is a temporary, signed link that lets someone upload or download a file directly to/from S3 without needing AWS credentials.

Usually, only IAM users/roles with the right S3 permissions can upload files.
But the browser (frontend) shouldn’t have AWS keys hardcoded (that’s unsafe ).
Instead, the backend Lambda/Flask app generates a presigned URL with an expiry (1 hour).
The browser then uploads the file directly to S3 using that link, skipping the backend.

Now, for this, we have the /presign route in lambda_function.py

So before uploading, the frontend asks the backend for a temporary signed upload link, i.e.

GET /presign?key=uploads/myfile.set

Backend then generates the temp. URL thru boto3 and returns JSON.

Then, the frontend(browser) with URL uploads directly to S3.

But then you might question Why go through this roundabout way when we could have just uploaded it to Lambda.

Well, that’s because the API Gateway payload cap is 10 MB. And so if your upload is bigger than that (which is the case here) is rejected. Whereas the S3 method is built for scale.

Mistakes

Now, even with an online guide and ChatGPT’s help, I made several mistakes, and below is the list of them :

Mistake 1: ECR “image index” vs “image”

When uploading the files from my local machine to ECR, I used Docker Buildx by default. This leads to Artifact type: Image Index in ECR. However, the Lambda only accepts a single-image manifest (Linux/Amd64), which results in the error.

So to fix this, we had to force the use of the classic Builder, so the result is a single manifest (not an index).

Mistake 2: Use compatible versions

The newer Tensorflow (2.17+) pullsKeras 3, which needs optree.

And the AWS base lambda images don't have any prebuilt optree. And now this optree uses C++. So when we pip install tensorflow, it tries to compile optree from source. To compile, you need gcc,g++,cmake , and Unix Makefiles. These aren’t in the standard Lambda image.
This leads to a compilation error, and if we want to include them, it leads to a much bigger Docker image.
So to fix this, I used TensorFlow 2.15 (Keras v2 bundled). This has no Keras 3, thus no optree.

Mistake 3: Missing Permissions for S3 Access

So while setting up the IAM role, I didn’t realize that I needed to explicitly allow the Lambda’s role to read/write on the bucket. After some head-scratching and checking error logs, it finally dawned on me.

So I updated my Lambda’s execution role to include S3 access permissions (allowing GetObject and PutObject on my bucket). Only then could my function fetch the uploaded EEG files from S3 and save results if needed.

Mistake 4: Forgetting About CORS (Cross-Origin Resource Sharing)

So my browser would try to call the Lambda’s API Gateway endpoint, but it was the browser’s CORS policy.

This was super annoying because the error isn’t from my code or AWS, but from the browser for security reasons. The culprit was me forgetting to enable CORS on my API Gateway and S3 bucket.

I eventually discovered that I needed to configure CORS so that my static site could call the API and upload to S3. In fact, I even added a note in my app’s footer reminding future me to do this: “Make sure CORS is enabled on API Gateway and your S3 bucket.”

After enabling CORS in API Gateway (allowing my domain/localhost and the necessary HTTP methods) and adding an appropriate CORS policy on the S3 bucket, the front-end and back-end finally started communicating properly.

Mistake 5: Misconfiguring the API Gateway (AKA "Why Am I Getting 404?")

After all these, when I hit my api, I got HTTP 404 errors. So I double-checked my Lambda code – the functions for /predict and /health existed.

But then I realized that the mistake was in my API Gateway configuration. I had not set up the resource paths or integrations properly for the routes.
API Gateway wasn’t forwarding /predict or /health to my Lambda at all, hence the 404s.
So when I hit …/health from the browser, the API Gateway was actually expecting something like…/default/health, which obviously didn’t exist.

Once I spotted this, I went back into the AWS console, fixed the route definitions (making sure they matched what my client was calling), and deployed the API to the correct stage.

Conclusion

So while deploying, I made several mistakes like Docker manifests, dependency mismatches, missing IAM permissions, CORS errors, and API Gateway misconfigurations. Each of these mistakes slowed me down, but also forced me to understand how AWS Lambda, S3, and API Gateway really work together.

The final setup is simple for the user—upload an EEG file, wait a few seconds, and get a prediction with confidence. But behind the scenes, there’s a careful system: S3 for storage, presigned URLs for secure uploads, Lambda containers for inference, and API Gateway as the bridge.

So if you’re taking your first model to the cloud, expect some bumps—but also expect to come out the other side with much sharper engineering instincts.
👉 You can try the deployed app here: Link
👉 Code is available on GitHub

vivekvohra / EEG-CNN-BiLSTM

Deep Learning for Alzheimer’s Detection from EEG Data

EEG-CNN-BiLSTM (AWS Lambda + S3 demo)

End-to-end demo that serves a Keras CNN-BiLSTM EEG classifier from AWS Lambda (container image) with a static frontend on S3 You can upload an EEGLAB .set file (or run a demo prediction), and get class probabilities back.

Live:https://az-eeg-site-109598917777.s3.ap-south-1.amazonaws.com/index.html
Blog:https://dev.to/vivekvohra/deploying-a-cnn-bilstm-model-on-aws-lambda-4kcj

EG-CNN-BiLSTM/
├── backend/                  # Lambda + Docker code
│   ├── lambda_function.py
│   ├── preprocess.py
│   ├── Dockerfile.dockerfile
│   ├── requirements.txt
│   └── model/
│       └── alzheimer_eeg_cnn_bilstm_model.h5
├── frontend/                 # S3 static site
│   ├── index.html
│   ├── app.js
│   └── style.css
├── research/                 # papers & notebooks
│   ├── train.ipynb
│   └── conference.pdf
├── LICENSE
└── README.md

Demo video

Recording.2025-09-18.003432.mp4

What’s inside

Model: Keras .h5 CNN-BiLSTM saved with TF 2.x (pinned to TF 2.15 at runtime).
Backend (backend/):
- lambda_function.py – Flask app wrapped by serverless-wsgi for API Gateway HTTP API.
- preprocess.py – loads .set and prepares input…

View on GitHub

Tideman Voting Algorithm: A Graph-Based Approach to Elections

Vivek Vohra — Sat, 13 Sep 2025 16:02:53 +0000

Understanding the Tideman Voting Algorithm: A Graph-Based Approach

The Tideman algorithm, also known as "ranked pairs," is a sophisticated voting system that leverages graph theory to determine election winners. By allowing voters to rank candidates in order of preference, it captures more nuanced voter intentions than simple plurality voting systems. This blog post explores the theoretical foundations of the Tideman algorithm, focusing on its graph-based approach and key mechanisms.

The Graph Theory Foundation

At its core, the Tideman algorithm represents an election as a directed graph:

Nodes represent candidates
Edges represent preferences of one candidate over another

This approach creates what's called an adjacency matrix where locked preferences between candidates are recorded. In the matrix example shown in the image, "true" values indicate a locked preference (or edge) between candidates.

For example, in the matrix shown, we can see that:

Candidate 0 is preferred over candidate 1
Candidate 2 is preferred over candidate 0
Candidate 2 is preferred over candidate 1

These locked preferences collectively form the final graph that determines the winner.

The Preferences Array

The preferences array is a fundamental data structure in the Tideman algorithm. It records how many voters prefer one candidate over another:

preferences[i][j] represents the number of voters who prefer candidate i over candidate j

For an election with three candidates (represented as 0, 1, and 2), the preferences array might look like this:

	0	1	2
0		5	3
1	4		6
2	7	2

In this example, 5 voters prefer candidate 0 over candidate 1, 3 voters prefer candidate 0 over candidate 2, and so on. The diagonal cells remain empty because a candidate cannot be compared with themselves.

Recording Voter Preferences with the Ranks Array

Tideman tracks individual voter preferences using a ranks array. For each voter, this array stores their candidate rankings where:

The index represents the rank (0 being the highest preference)
The value represents the candidate ID

For example, in an election with Alice (0), Bob (1), Charlie (2), and David (3) as candidates, if a voter prefers Bob most, followed by Alice, then David, and finally Charlie, their ranks array would be:

ranks = 1, ranks[1] = 0, ranks[2] = 3, ranks[3] = 2

This means at rank 0 (highest preference), they chose candidate 1 (Bob), at rank 1 they chose candidate 0 (Alice), and so on.

Sorting Candidate Pairs by Strength of Victory

After collecting all votes, the algorithm creates "pairs" of candidates where one is preferred over another. These pairs are then sorted by strength of preference (how many more voters prefer one candidate over the other).

The algorithm uses merge sort to efficiently organize these pairs, ensuring that the strongest preferences are considered first when building the final graph.

The Lock Pairs Function: Avoiding Cycles

The most crucial part of Tideman is the lock_pairs function, which determines which preferences to "lock in" to the final graph. There are two main approaches to implementing this function:

Method 1: Column Check

A graph remains non-cyclic if at least one column in the adjacency matrix contains all "false" values. This is an observation that requires checking all columns.

Method 2: Cycle Detection

The more sophisticated approach is to check if locking a pair would create a cycle in the graph. A cycle occurs when following the preference edges leads back to the starting candidate.

Cycle Detection in Practice

Let's see how cycle detection works with an example:

Candidates = [a, b, c, d]
Sorted Pairs = [(d, a), (a, b), (b, c), (c, a), (d, b), (d, c)]

Looking at pair (d, a): No prior locked pairs, so we can lock this. Graph: d → a
Looking at pair (a, b): No cycle created, so we lock it. Graph: d → a → b
Looking at pair (b, c): No cycle created, so we lock it. Graph: d → a → b → c
Looking at pair (c, a): This would create a cycle c → a → b → c, so we don't lock it.
Looking at pair (d, b): No cycle created, so we lock it. Graph now includes d → b
Looking at pair (d, c): No cycle created, so we lock it. Final graph includes d → c

The final graph looks like:

		a
	➚	↓
d	➙	b
	➘	↓
		c

The key insight is that we only skipped locking pair (c, a) because it would have created a cycle.

Finding the Winner

After locking all valid pairs, the winner is the candidate with no incoming edges in the final graph - the "source" of the directed graph. This candidate is not beaten by any other candidate according to the locked preferences.

In our example, candidate d has no incoming edges, making it the winner.

Theoretical Significance

The Tideman algorithm elegantly solves several problems in voting theory:

It finds a Condorcet winner when one exists (a candidate who would win head-to-head against all others)
It provides a reasonable approximation when no Condorcet winner exists
It satisfies the Independence of Irrelevant Alternatives criterion better than many other voting systems

By using graph theory to represent voter preferences, Tideman creates a more complete picture of the election results than simpler methods like plurality voting.

Conclusion

The Tideman algorithm represents a sophisticated application of graph theory to voting systems. By considering the full spectrum of voter preferences and carefully constructing a directed graph that avoids cycles, it provides a more nuanced and representative election outcome.

Understanding the theoretical foundations of Tideman - from preference arrays and rank recording to cycle detection and winner determination - gives us insight into how modern voting systems can better capture voter intent and produce fairer election results.

Deploying Tideman Election App on AWS EC2 with Docker

Vivek Vohra — Sat, 13 Sep 2025 15:59:03 +0000

I recently took my Tideman app from my laptop to the cloud, and getting it live on AWS EC2 with Docker turned out to be simpler than I expected.

Setting Up my EC2 Instance

First, I launched an AWS EC2 instance with Ubuntu as the operating system. I chose a small instance (free tier eligible) since my app isn’t too heavy.

After launching, I configured the instance’s Security Group to allow the right ports:

Port 22 (SSH) so I could connect to the server’s terminal.
Port 80 (HTTP) so the web app would be accessible in a browser.

Afterwards, I installed Docker and cloned my code to the EC2 instance.

# On the EC2 instance
sudo apt-get update
sudo apt-get install -y docker.io git

# (Optional) clone your repo and move into it
git clone <your-repo-url>
cd <your-repo-folder>

Writing a Multi-Stage Dockerfile

Now for the main part: containerizing the app with Docker.

I created a file named Dockerfile in the project directory. Because my app has two components (C++ and Python), I used a multi-stage Docker build to keep the final image lean. Here’s how I set it up:

Stage 1: Build the C++ Program

In the first stage, I used a Docker image with a C++ compiler to compile the algorithm:

# Stage 1: Compile C++ code
FROM gcc:latest AS builder       # Use GCC compiler image
WORKDIR /app

# Copy in the C++ source code and compile it
COPY my_algorithm.cpp /app/my_algorithm.cpp
RUN g++ my_algorithm.cpp -o my_algorithm

This stage grabs the official GCC image, copies my C++ source file into it, and runs g++ to compile the code into an executable (my_algorithm).

Stage 2: Set Up Python + Flask

For the second stage, I wanted a lightweight Python environment to run Flask and the compiled binary. I chose a slim Python image:

# Stage 2: Run Flask app with Gunicorn
FROM python:3.10-slim AS final   # Use a small Python image
WORKDIR /app

# Copy the compiled C++ binary from the builder stage
COPY --from=builder /app/my_algorithm /app/my_algorithm

# Copy the Flask app code and any other files
COPY app.py /app/app.py
COPY index.html /app/index.html
COPY requirements.txt /app/requirements.txt

# Install Flask (and Gunicorn) via requirements
RUN pip install -r requirements.txt

# Expose port 5000 and start the app using Gunicorn
EXPOSE 5000
CMD ["gunicorn", "-b", "0.0.0.0:5000", "app:app"]

What’s happening in Stage 2:

We switch to a Python 3 slim image (much smaller than a full Ubuntu or GCC image).
Copy the compiled C++ binary from stage 1 into this new image. This way, the Python container can use the C++ program without needing a compiler.
Copy over the Flask app (app.py), the index.html, and a requirements.txt listing Python dependencies.
Install dependencies: I included Flask (and Gunicorn for the server) in requirements.txt, so pip install -r requirements.txt pulls those into the container.
Finally, set the container to listen on port 5000 and define the startup command: here I use Gunicorn to run the Flask app.

The multi-stage approach means our final image (stage 2) does not include all the bulky build tools from stage 1.
We only carry over the compiled binary and needed files. This makes the final Docker image smaller and cleaner, which is great for efficiency and security.

Building and Running the Docker Container

With the Dockerfile written, I proceeded to build the image on the EC2 instance:

sudo docker build -t myflaskcpp .

Next, I ran the container. This is where the port configuration is important. My Flask app (via Gunicorn) is set to run on port 5000 inside the container. But I want people to access it through the standard HTTP port 80 on the EC2 instance. So I used a port mapping:

sudo docker run -d -p 80:5000 myflaskcpp

Here, -p 80:5000 maps port 80 on the host (the EC2 instance) to port 5000 inside the container. Now, any request hitting the EC2’s public IP on port 80 will be forwarded to the Flask app in the container. I ran the container in detached mode (-d) so it runs in the background.

Note: Make sure you opened port 80 in the EC2 security group. Otherwise, you won’t be able to reach the app from your browser.

Why Use Gunicorn instead of Flask’s Dev Server?

You might wonder why I’m using Gunicorn in the Dockerfile, rather than just running the development server:

python app.py

The reason is that Flask’s built-in server (the one you get with app.run()) is meant for development only. It’s single-threaded by default and not optimized for multiple users or production stability.

Gunicorn, on the other hand, is a production-ready WSGI server. It can handle multiple requests at the same time by running several worker processes. This means if one user is making a slow request, other users can still be served in parallel. Gunicorn is also well-tested for deployment, making your app more robust under real-world traffic. In short, using Gunicorn ensures our Flask app will be able to handle more than one person at a time and won’t crash at the first sign of stress.

Wrapping Up

Now grab the EC2 instance’s public IP and check if it works.

And that’s it! We have managed to get a C++ algorithm and a Flask web interface deployed on AWS using Docker. As someone new to combining these technologies, it felt great to see it running live.

Key Takeaways

Use EC2 security groups to open the ports you need (SSH and HTTP in this case).
Docker multi-stage builds can mix languages (compile in one stage, run in another) to keep things efficient.
Map your container’s internal ports to the server’s ports so the world can reach your app.
Gunicorn is your friend for serving Flask in production.

Happy deploying! 🚀

vivekvohra / tideman

Tideman Electoral System

Tideman’s Ranked Pairs method (developed by Nicolaus Tideman) is a ranked-choice voting algorithm that selects a single winner by constructing a directed graph of pairwise victories and locking in the strongest preferences while avoiding cycles.

This repository provides an object-oriented, benchmarked, file-driven C++17 implementation, wrapped by a Flask API and a minimal HTML front end. It’s now Dockerized (multi-stage) and EC2-ready with Gunicorn for a production-style run.

Live demo: http://13.200.175.4/

Features

CSV input with support from thousands up to millions of ballots
High-resolution benchmarking using <chrono>
Object-oriented design (TidemanElection, VoteParser, Benchmark)
Robust error handling (bad input, duplicates, file issues)
Efficient in practice: millions of ballots with ≤9 candidates in milliseconds
Web service wrapper: C++ executable exposed via Flask API + HTML
Containerized: Multi-stage Dockerfile, Gunicorn server, EC2-ready (port 80 → 5000)

Sample Input (CSV Ballots)

Example…

View on GitHub

Detecting Alzheimer’s Disease using a CNN-BiLSTM Architecture

Vivek Vohra — Sat, 10 May 2025 19:08:23 +0000

Abstract

Alzheimer's disease (AD) represents a significant global health challenge. This paper proposes an experimental approach for early AD detection using Electroencephalography (EEG) signals processed through an innovative deep-learning architecture. I suggest a channel-frequency-based attention model that effectively captures spectral features across different brain regions. This model uses depthwise convolutions, squeeze-and-excitation blocks, and spatial dropout regularization to efficiently learn patterns within EEG data. The dataset has 19-channel EEG recordings from subjects with Alzheimer's, healthy controls, and frontotemporal dementia. The model shows 83.81% accuracy, which tells us about its potential.

Introduction

Alzheimer's disease (AD) is a progressive neurodegenerative disorder that affects millions of people in the world and shows gradual cognitive decline, memory loss, and behavioral changes. Many individuals delay seeking medical help because they attribute memory loss to natural aging, leading to late diagnosis when treatment is too late.

Current diagnostic procedures for AD often rely on invasive and expensive methods such as Positron Emission Tomography (PET). Thus, we need a non-invasive, cost-effective, and readily accessible tools for early AD detection. Electroencephalography (EEG) is a good candidate because of its non-invasive nature and relatively low cost.

Several studies have shown that increased power in low-frequency bands like delta and theta, and decreased power in higher bands like alpha and beta, can serve as biomarkers for early AD detection.

Deep learning models can automatically learn patterns from raw or minimally processed data that might escape traditional analysis methods.

This paper proposes a DL model for AD detection using EEG signals. Our model captures patterns in EEG data, focusing on relative band power features from five frequency bands: alpha, beta, gamma, delta, and theta. The key contributions of this paper include:

A channel-frequency attention model that tries to capture the relationship between different brain regions and frequency bands
Preprocessing pipeline for extracting relative band power(RBP) features from preprocessed EEG signals
Analysis of the model's performance.

Deep Learning for EEG Analysis

The application of deep learning to EEG analysis has gained significant traction in recent years, offering the potential to automatically learn relevant features from minimally processed data. Various deep learning architectures have been explored for EEG-based AD detection, including convolutional neural networks (CNNs), recurrent neural networks (RNNs), deep belief networks (DBNs), and, more recently, transformers.

Zhao (2014) was among the early researchers who applied deep learning to EEG-based AD diagnosis, using a deep auto-encoder network to extract features from time-domain EEG data4. The study demonstrated that deep learning could discriminate between AD patients and healthy controls without requiring manual feature engineering. Building on this work, more recent studies have developed increasingly sophisticated architectures.

Ieracitano et al. (2019) proposed a CNN model for EEG-based AD detection, achieving high classification accuracy by learning directly from time-frequency representations of EEG signals. Similarly, Huggins et al. (2020) employed an AlexNet-based architecture to classify EEG data transformed into time-frequency graphs using continuous wavelet transform, achieving an impressive accuracy of 98.90% for three-class classification.

More recently, Wang et al. (2024) introduced LEAD, a large foundation model for EEG-based AD detection. This approach employed contrastive learning on a large corpus of EEG data from various neurological disorders, followed by fine-tuning on AD-specific datasets. The model demonstrated significant improvements over previous methods, highlighting the potential of transfer learning and self-supervised approaches in limited AD-specific data7.

Challenges in EEG-Based AD Detection

Despite promising results, several challenges are faced in EEG-based AD detection. One of the significant challenges is variations observed between different individuals, making it difficult to develop a model that generalizes well to new demographics of subjects. EEG signals are influenced by various factors, including gender, medication, and age, making it challenging to isolate AD-specific patterns.

Another one of the challenges is the limited availability of high-quality EEG datasets. Most of the dataset involves small numbers of subjects, which limits the generalization of the models trained on it.

Data quality is also a significant concern, as EEG recordings are susceptible to various artifacts, including eye movements, muscle activity, and environmental noise. Preprocessing the data can mitigate these issues, but might also remove crucial relevant information and introduce biases in the dataset.

Finally, understanding the specific features or patterns these deep learning models detect remains challenging. This "black box" nature can hinder clinical adoption, as healthcare providers generally prefer diagnostic tools with clear, interpretable rationales.

Proposed Model

Data Acquisition and Preprocessing

Our study utilized EEG data from a dataset containing recordings from subjects diagnosed with Alzheimer's disease (labeled 'A'), frontotemporal dementia (labeled 'F'), and healthy controls (labeled 'C'). The dataset included 19-channel EEG recordings following the standard 10-20 international system for electrode placement.

Fig. 1. Flowchart of the EEG preprocessing pipeline. Raw EEGLAB .set files are filtered, epoched, and processed using Welch's method to compute PSD. Relative Band Power (RBP) features are extracted and then standardized before being input to the classification model.

The preprocessing pipeline consisted of several steps designed to extract meaningful features while minimizing artifacts:

Data Loading and Label Mapping: We loaded the EEG data using MNE-Python and mapped the diagnostic groups to numeric labels (0 for Alzheimer's, 1 for frontotemporal dementia, and 2 for healthy controls).
Signal Filtering: We applied a bandpass filter (0.5-45 Hz) to remove artifacts and retain only the frequency bands relevant to our analysis. This step eliminated power line noise (typically at 50 or 60 Hz) and very low-frequency drifts.
Epoching: Continuous EEG recordings were segmented into 2-second epochs with a 1-second overlap. This approach allowed us to capture transient neural patterns while generating sufficient samples for model training.
Spectral Analysis: We computed the power spectral density (PSD) for each epoch using Welch's method, which provides a robust estimate of the frequency content of EEG signals by averaging the periodograms of overlapping segments.
Relative Band Power Extraction: We extracted relative band power (RBP) features for five standard EEG frequency bands:
- Delta (0.5-4 Hz): Associated with deep sleep and pathological states
- Theta (4-8 Hz): Linked to drowsiness and some pathological conditions
- Alpha (8-13 Hz): Predominant during relaxed wakefulness
- Beta (13-25 Hz): Related to active thinking and focus
- Gamma (25-45 Hz): Associated with cognitive processing and perceptual binding

Fig. 2. Conceptual diagram of Relative Band Power (RBP) feature generation for a single epoch. Power Spectral Density (PSD) is computed using Welch's method. Power is then aggregated and normalized for five key frequency bands (Theta, Delta, Alpha, Beta, Gamma), producing a 19x5 feature map (19 channels x 5 frequency bands) used as input features

The relative band power was calculated by dividing the absolute power in each frequency band by the total power across all bands, resulting in a normalized measure that reduces the impact of inter-subject variability in overall signal amplitude.

Feature Reshaping: The extracted RBP features were reshaped into a 4D tensor (epochs, channels, frequency bands, 1) suitable for input to our convolutional neural network.
Data Splitting and Standardization: The dataset was split into training (80%) and testing (20%) sets, and standardization was applied to normalize the feature distributions, improving training stability and model performance.

The final input to our model had the shape (N, 19, 5, 1), representing N epochs, 19 EEG channels, five frequency bands, and one feature (relative band power).

Model Architecture

We propose a hybrid deep learning model combining Convolutional Neural Networks (CNNs) and Bidirectional Long Short-Term Memory (BiLSTM) networks for AD detection. The model processes Relative Band Power (RBP) features extracted from 2-second non-overlapping EEG epochs. These features are structured as input tensors of shape (19, 5, 1), representing 19 EEG channels, 5 canonical frequency bands (Delta: 0.5-4Hz, Theta: 4-8Hz, Alpha: 8-13Hz, Beta: 13-25Hz, Gamma: 25-45Hz) [Adjust band definitions if different], and a single feature dimension (power).

Fig. 3. Proposed CNN–BiLSTM classification architecture.

The architecture comprises:

CNN Feature Extractor:Processes the (19, 5, 1) input.
Block 1: Conv2D (32 filters, 3x3 kernel, L2 reg.) -> BatchNormalization -> ReLU -> MaxPooling2D (pool size (2, 1)), reducing the channel dimension while preserving frequency information.
Block 2: Conv2D (64 filters, 3x3 kernel, L2 reg.) -> BatchNormalization -> ReLU -> MaxPooling2D (pool size (2, 2)), downsampling both dimensions. This stage captures local spatial patterns across channels and spectral patterns within frequency bands.
Sequence Preparation: A Permute layer rearranges the CNN output dimensions to prioritize the frequency axis (batch, reduced_freqs, reduced_channels, filters), and A Reshape layer merges the channel and filter dimensions, creating a sequence input for the LSTM: (batch, sequence_length=reduced_freqs, features_per_step).
Sequential Modeling (BiLSTM): A Bidirectional LSTM layer (64 units, dropout, recurrent dropout, L2 reg.) processes the sequence of features derived from the frequency bands. This captures dependencies and contextual information across the spectral profile (e.g., relationships between alpha and beta band features). return_sequences=False is used for classification.
Classification Head: Dropout -> Dense (128 units, ReLU, L2 reg.) -> Dropout -> Dense (3 units, softmax activation) for final class prediction (A, F, C).

The model architecture is summarized in the following diagram:

Training Procedure

The model was trained using the Adam optimizer with a learning rate of 0.001 and a sparse categorical cross-entropy loss function. The dataset exhibited moderate class imbalance (Class A: ~42%, F: ~24%, C: ~34% of total epochs). Balanced class weights were computed using sklearn's 'balanced' mode and applied during training to mitigate this.

Training was regularized using L2 penalties on convolutional and dense layers, dropout in the LSTM and thick layers, and two callbacks: EarlyStopping (monitoring val_loss, patience 20, restoring best weights) and ReduceLROnPlateau (monitoring val_loss, factor 0.2, patience 7). Training ran for up to 100 epochs with a batch size of 128 on a dataset split into 80% training (~55k epochs) and 20% testing (~14k epochs). The final model weights were selected based on the lowest validation loss achieved during training.

Evaluation of the Proposed System

Experimental Setup

We evaluated our model using a rigorous experimental framework to assess its performance in classifying EEG signals from subjects with Alzheimer's, frontotemporal dementia, and healthy controls. The dataset was split into training (80%) and testing (20%) sets. We used accuracy, loss, and confusion matrices as our primary evaluation metrics.

The model is implemented using TensorFlow and Keras.

Results and Performance Analysis

The model achieved a test accuracy of 83.81% and a Log Loss of 0.4188. The Cohen's Kappa coefficient was 0.7520.

The per-class performance, as detailed in Table I, reveals generally robust results across all classes. Class C ('Control') achieved the highest precision (0.8751) and a high recall (0.8478), leading to the best F1-score (0.8612). Class A ('Alzheimer's') also performed well with balanced precision and recall (0.8407). Class F ('Frontotemporal Dementia') exhibited slightly lower metrics, with an accuracy of 0.7838 and recall of 0.8195 (F1-score: 0.8012).

Table I: Classification Report

Class	Precision	Recall	F1-Score	Support
A	0.8407	0.8407	0.8407	5724
F	0.7838	0.8195	0.8012	3335
C	0.8751	0.8478	0.8612	4883
Accuracy			0.8381	13942
Macro Avg	0.8332	0.8360	0.8344	13942
Weighted Avg	0.8391	0.8381	0.8384	13942

This table summarizes the model's performance across three classes (A, F, C) in terms of precision, recall, and F1-score. The weighted and macro averages provide a holistic view of the model’s overall performance. Accuracy denotes the overall proportion of correctly classified instances.

Further analysis using the Area Under the Receiver Operating Characteristic Curve (AUC) with a One-vs-Rest strategy indicated excellent class separability at the probability level. The AUC scores were 0.9454 for Class A, 0.9558 for Class F, and 0.9625 for Class C, with a Macro Average AUC of 0.9546.

The normalized confusion matrix (Fig. Y - refer to the heatmap figure) provides insights into specific error patterns. The diagonal elements confirm the high recall values for each class (A: 0.84, F: 0.82, C: 0.85). The most notable misclassifications occurred where 13% of actual Class F instances were predicted as Class A, and 10% of actual Class C instances were predicted as Class A. Other misclassifications were less frequent (<= 8%). These results suggest that while the model effectively distinguishes the classes overall, there is some residual confusion, particularly in differentiating classes F and C from class A based on the learned spectral patterns.

Fig. 4. Normalized confusion matrix (recall) of the proposed CNN–BiLSTM model across classes A, F, and C..

Model Interpretability

The model's architecture suggests a tier-wise feature learning process. The CNN layers help to identify local patterns within the channel-frequency RBP representation (e.g., focal slowing, specific band power ratios). The BiLSTM subsequently models how these patterns relate across the frequency spectrum (delta through gamma). The observed high performance, particularly the high AUC scores, suggests the model successfully learned discriminative spectral profile characteristics for each class.

Observation

The hybrid CNN-BiLSTM model shows convergence during training: the loss decreases smoothly over epochs, and its accuracy improves until it plateaus, indicating effective learning of the EEG features. Training accuracy is slightly higher than the 83.81% test accuracy, implying good generalization. This suggests limited overfitting.

The CNN-BiLSTM architecture effectively combines spatial and temporal feature extraction. Convolutional layers learn spatial patterns from EEG band powers, while the BiLSTM captures temporal dynamics. The strong performance metrics (83.81% accuracy, Kappa 0.7520, macro AUC 0.9546) indicate excellent class discrimination.

Nonetheless, some class confusion remains. The overlaps in EEG spectral features for FTD and controls lead to misclassification. Cohen’s Kappa (0.7520) indicates substantial agreement, and the high AUC (0.9546) shows each class is well separated on average.

Conclusion

The main contribution of this work is a CNN-BiLSTM model that uses EEG spectral features to classify Alzheimer’s Disease, Frontotemporal Dementia, and healthy controls. The model’s high accuracy (83.81%), substantial Kappa (0.7520), and macro AUC (0.9546) demonstrate its effectiveness and potential utility for practical dementia screening. The results suggest that CNN-BiLSTM can successfully capture EEG patterns relevant to these conditions.

However, challenges remain, particularly class confusion between FTD and controls. This indicates that we need to incorporate more discriminative features. Future directions include adding advanced spectral ratios or connectivity biomarkers and training the model on more diverse and larger datasets.

Fibonacci heaps—a fascinating data structure that cleverly balances lazy operations with efficiency.

Vivek Vohra — Sun, 16 Mar 2025 13:31:31 +0000

Fibonacci Heaps

Vivek Vohra ・ Mar 16

#algorithms #computerscience #programming #tutorial

Fibonacci Heaps—a fascinating data structure that cleverly balances lazy operations with efficiency.

Vivek Vohra — Sun, 16 Mar 2025 13:31:06 +0000

Fibonacci Heaps

Vivek Vohra ・ Mar 16

#algorithms #computerscience #programming #tutorial

Fibonacci Heaps

Vivek Vohra — Sun, 16 Mar 2025 13:28:32 +0000

This post explores one of computer science's most beautiful data structures—the Fibonacci Heap.

The Fibonacci Heap is a specialized priority queue data structure consisting of a collection of heap-ordered trees. Each tree satisfies the min-heap property.

The Fibonacci Heap is a specialized priority queue data structure consisting of a collection of heap-ordered trees. Each tree satisfies the min-heap property, meaning each parent node has a key less than or equal to its children's keys. Let's explore this clever data structure's technical details and inner workings.

A Fibonacci heap consists of multiple trees stored in a circular doubly-linked list called the root list. Each node within these trees contains pointers to:

Its parent node
One of its children
Its left and right siblings (due to the circular doubly-linked nature)
A boolean "marked" flag indicating whether it has lost a child since becoming a child of another node.

This linked structure allows constant-time insertion, deletion, and merging operations by updating pointers.

Key Operations:

Insert Operation

The idea is to be lazy; here, we add the number to the root list and then update the pointer to the minimum element.
This operation is performed in O(1) amortized time complexity.

Merge Operation

While merging two Fibonacci, we join both root lists by updating the root node to whichever has the smallest key. And the other root node points to it.

Extract-Min Operation

Extracting the minimum element is more complex and has multiple steps:

Remove Minimum Node:
- Remove the node pointed to by the minimum pointer from the root list.
- Add all its children directly into the root list as separate trees.
Clean Up:

We must reduce the number of trees in our root list to maintain efficiency. We do this by repeatedly merging trees with identical degrees:
- We use an auxiliary array indexed by node degree.
- We only allow one node to exist per degree and merge if there is more than one.

This ensures that no two trees have identical degrees after Extract-Min completes, keeping node degrees low.

Update Minimum Pointer: All resulting trees have distinct degrees, just like a Binomial Heap.

Decrease-Key Operation

Decrease-Key operation reduces a node's key value and adjusts its position within the heap:

Decrease the key value directly at its current position.
If this violates the heap property (the node becomes smaller than its parent), remove that node from its parent and move it to the root list.
Mark any parent losing one child; if a marked parent loses another child later, cut that parent out recursively as well.
Update minimum pointer if necessary.

The above technique is known as controlled Node Cuts or Cascading Cuts. It ensures that each node retains a certain minimum number of descendants relative to its degree.

Specifically, for any given node with degree d, the smallest possible subtree rooted at that node contains at least F_{d+2} nodes, where F_i denotes the i th Fibonacci number.

Why Fibonacci Numbers Appear:

Now consider the smallest possible tree for each degree after allowing cascading cuts:

A tree with degree 0 has 1 node.
A tree with degree 1 also minimally has 2 nodes.
Each subtree rooted at a child node must have at least certain minimal degrees for higher degrees due to our "one-child-loss" rule.
It turns out that this minimal subtree size precisely follows the Fibonacci sequence:
- The size of the smallest possible tree for degree d equals the sum of sizes of two previous smaller-degree minimal trees, which exactly matches how Fibonacci numbers are defined.

For example:

A degree-0 tree contains F_2 = 1 node.
A degree-1 tree contains F_3 = 2 nodes.
A degree-2 tree contains F_4 = 3 nodes.
A degree-3 tree contains F_5 = 5 nodes.
A degree-4 tree contains F_6 = 8 nodes.

In conclusion, Fibonacci Heaps balances laziness (fast Insert and DecreaseKey) with periodic cleanup (ExtractMin consolidations), ensuring optimal amortized complexity for priority queue operations. This design leverages amortization and binomial tree structures to achieve these impressive theoretical guarantees.

Operation	Fibonacci Heap Complexity
Insert	Amortized O(1)
ExtractMin	Amortized O(log n)
DecreaseKey	Amortized O(1)
Merge	Amortized O(1)

This insightful YouTube video explains The Fibonacci Heap operations in detail: https://www.youtube.com/watch?v=6JxvKfSV9Ns&t=1561s

Convolution

Vivek Vohra — Fri, 07 Mar 2025 20:14:09 +0000

CONVOLUTION

CONVOLUTION is a mathematical operator “*”.Graphically, it expresses how the 'shape' of one function is modified by the other.

It is applicable only to Linear Time Invariant Systems.

Time Invariant: systems where a shift in input results in an identical shift in output.eg:

Linear:In simple terms it is a graph between output and input which must be a straight line through the origin without having saturation or dead time.

For discrete systems, the formula is :

https://youtu.be/QmcoPYUfbJ8?si=2CCf64_x9fGl7jx5

In this video, we understand convolution using a great analogy. Suppose we want to find how much smoke burning several matchsticks produce. Here we take a time frame of 5 minutes. Let's define 2 functions:

Smoke function: S(t) - It describes the amount of smoke produced by a single matchstick across time. It might be an exponential decay graph.

Firework function: F(t)- It describes the number of matchsticks lit per minute.
Let it be a linear function. y = x

t=0 1 match was lit
t=2 2 matches were lit: total smoke = smoke from 2 sticks at present = 2*S(0) (because for matchsticks at this time they just started burning) + smoke of prev. 1 stick after 1 sec. of burning = 1*S(1).

at minute 0	1*S(0)
at minute 1	2S(0)+ 1S(1)
at minute 2	3*S(0) + prev(t + 1)

Thus we can conclude that it indeed follows the above equation.

We can visualize convolution as a sliding window:

Now if are 1st function is very large as compared to our 2nd function

Our visualization will be somewhat like this:

In 2-D version(Image processing)

or using Alternate illustration :

In the 2-D function, we can solve this Matrix convolution at (2,2) by flipping and multiplying.

i.e. = (i*1)+(h*2)+(g*3)+(f*4)+ (e*5) + (d*6) + (c*7) + (b*8) + (a*9)

In Image Processing, the 2nd function is known as Kernel which is in this case 3x3 matrix

[1/9, 1/9, 1/9],

[1/9, 1/9, 1/9]

We could have solved our Blur function by taking our 2nd function such that it sum of all nodes is 1 and then doing the convolution. (Remember while multiplying we have to flip the Matrix!!).

[Boost]

Vivek Vohra — Thu, 20 Feb 2025 09:06:15 +0000

Part 1: Detecting Alzheimer’s with EEG and Deep Learning – Theory, Motivation, and Preprocessing

Vivek Vohra ・ Feb 20

#ai #deeplearning #machinelearning #tensorflow

Part 1: Detecting Alzheimer’s with EEG and Deep Learning – Theory, Motivation, and Preprocessing

Vivek Vohra — Thu, 20 Feb 2025 09:00:17 +0000

Introduction

Alzheimer’s disease (AD) is a challenging neurodegenerative disorder that affects millions of people worldwide. Many people delay seeking medical help because they believe memory loss is a natural part of growing old. This leads to late diagnosis and fewer treatment options. Traditional diagnostic tools like PET scans, cerebrospinal fluid tests, and MRI are invasive, costly, and not easily accessible.

As part of my ongoing research efforts, I deployed an experimental prototype that uses an EEG data set from OpenNeuro, combined with machine learning, to explore early detection of Alzheimer’s. Although this work is experimental and will not be used in the final research publication, it has deepened my skills in signal processing, feature extraction, and model development.

Why Alzheimer’s Detection Matters

Early detection of Alzheimer’s can lead to timely intervention, which may slow the progression of the disease and improve the quality of life for patients as this disease is non-curable. Studies have shown that increased theta power, decreased alpha power, and disrupted gamma coherence are often associated with Alzheimer’s. By applying deep learning to these spectral features, we aim to create a tool that could eventually assist clinicians in making early and accurate diagnoses.

Theoretical Background: PSD, DSP, and EEG Signals

A core part of this project is extracting power spectral density (PSD) features from EEG signals. PSD analysis reveals how the power of a signal is distributed across different frequencies. Using Welch’s method— an approach that divides the signal into overlapping segments, computes the Fast Fourier Transform (FFT) on each, and averages the results— we obtain a reliable estimate of the PSD.
This process is a fundamental aspect of digital signal processing (DSP) and helps transform raw EEG data into a structured frequency-domain representation that highlights biomarkers related to Alzheimer’s.

The Preprocessing Pipeline

Before training the model, raw EEG recordings must be transformed into meaningful features. The dataset used here is from OpenNeuro, which is already extensively preprocessed, providing a clean dataset. Here’s a breakdown of the preprocessing steps implemented:

1. Data Loading and Label Mapping

We begin by loading EEG data using MNE-Python and reading participant metadata from a TSV file. The metadata maps diagnostic groups—‘A’ for Alzheimer’s, ‘F’ for Frontotemporal Dementia, and ‘C’ for healthy controls—to numeric labels.

import pandas as pd

metadata = pd.read_csv('Dataset/participants.tsv', sep='\t')
group_mapping = {'A': 0, 'F': 1, 'C': 2}  # Map diagnostic groups to integers
metadata['label'] = metadata['Group'].map(group_mapping)
subject_labels = dict(zip(metadata['participant_id'], metadata['label']))

This mapping is essential because it links each subject’s EEG data with their clinical result, thus helping us with supervised learning.

2. EEG Signal Processing

Although this EEG data was cleaned, it still had several unwanted frequencies. We only need specific frequencies for our analysis, so we apply an FIR filter (0.5–45 Hz) to remove unwanted frequencies (e.g., power line noise).


raw.filter(0.5, 45, fir_design='firwin')

Then, we segment the continuous data into 2-second epochs with a 1-second overlap. This step captures transient neural patterns relevant to Alzheimer’s.


epochs = mne.make_fixed_length_epochs(raw, duration=2.0, overlap=1, preload=True)

3. PSD Calculation and Feature Extraction

We use Welch’s method to compute the PSD for each epoch and then extract relative band power (RBP) features for the standard EEG frequency bands: delta, theta, alpha, beta, and gamma. This step involves averaging the power within each frequency range and normalizing by the total power, resulting in a 4D tensor (epochs, channels, bands, 1) suitable as input for a deep learning model.

psd = epochs.compute_psd(method="welch", fmin=0.5, fmax=45)
PSDs, freqs = psd.get_data(return_freqs=True)

freq_bands = {
    "delta": (0.5, 4),
    "theta": (4, 8),
    "alpha": (8, 13),
    "beta": (13, 25),
    "gamma": (25, 45),
}

band_power = {}
for the band (fmin, fmax) in freq_bands.items():
    IDX = np.logical_and(freqs >= fmin, freqs <= fmax)
    band_power[band] = psds[:, :, idx].mean(axis=-1)

bp_abs = np.stack(list(band_power.values()), axis=-1)
total_power = bp_abs.sum(axis=-1, keepdims=True)
rbp_relative = bp_abs / total_power

features = rbp_relative.reshape(rbp_relative.shape[0], rbp_relative.shape[1], rbp_relative.shape[2], 1)

4. Label Vector Construction and Data Standardization

Finally, we associate each epoch with its corresponding diagnostic label using the metadata mapping and concatenate all subject features to form the final input matrix X. We also split our data into training and test sets. To improve training stability, we standardize X using StandardScaler, but this requires data to be in 2D shape, so we reshape our data, apply the functions, and then reshape it back to the original.

5. Final Data Format

After all these steps, if we print our final input matrix, we will feed it into our model, i.e., 'X.'

print("X shape:", X.shape)

We get the output :

X shape: (69706, 19, 5, 1)

The given implies :

69706 Epochs: This is the total number of epochs (or samples) extracted from all subjects. Each epoch represents a 2-second window of EEG data transformed into a feature map.
19 Channels: Each epoch's feature map has 19 rows, corresponding to 19 EEG channels.
5 Frequency Bands: The five columns in each feature map represent no. of frequency bands: delta, theta, alpha, beta, and gamma.
1 Channel (Grayscale Image): The final dimension (1) indicates that data is a single channel. This is analogous to a grayscale image. Each pixel value corresponds to a particular EEG channel's normalized relative band power in a specific frequency band.

Conclusion

This blog post has covered the theoretical background of power spectral density (PSD) and digital signal processing (DSP) as they relate to EEG signals, explained why EEG is a promising tool for Alzheimer’s detection, and detailed the preprocessing steps that transform raw EEG data into meaningful features for deep learning. Although the model is still experimental, this pipeline lays a strong foundation for my future improvements and learnings.

In Part 2, we will dive into the details of the model architecture and training strategies, discuss how machine learning components work to learn from these spectral features, and ultimately classify EEG recordings.

Please visit my GitHub repository, EEG-ML-Experiment, for a detailed look at the code and further updates.

vivekvohra / EEG-ML-Experiment

Automated EEG-Based Alzheimer’s Detection System

EEG-ML-Experiment

Welcome to the EEG-ML-Experiment repository! This repository is dedicated to exploring various experimental models for processing EEG data using deep learning techniques. The overall goal is to develop and test different approaches for tasks like Alzheimer’s detection using EEG signals. Although these projects are experimental, they serve as an important learning tool and a foundation for future research and development.

Overview

This repository contains multiple experimental models, each implemented in its own subdirectory along with a dedicated README file. The main focus is on leveraging EEG data—specifically, features extracted from power spectral density (PSD) and relative band power—for diagnostic purposes. This work is part of my ongoing research efforts, and while the models are still in development and experimental in nature, they represent a significant learning experience in applying machine learning to biomedical signals.