DEV Community: Harsha Raj Kumar

PyTorch Open-Source Contribution — Fixing a Zero-Dimension Edge Case in `torch.unravel_index`

Harsha Raj Kumar — Mon, 24 Aug 2026 17:12:58 +0000

Overview

I contributed a fix to the PyTorch codebase addressing an edge case in torch.unravel_index, and the change was reviewed and merged into PyTorch's main branch.

torch.unravel_index converts flat indices into coordinates for a tensor of a given shape. While investigating its behavior around zero-sized dimensions, I found a case where invalid input could propagate into the underlying computation and result in division/modulo by zero rather than being rejected with a meaningful validation error.

Merged PR: https://github.com/pytorch/pytorch/pull/191092

The Problem

Consider a tensor shape containing a zero-sized dimension while providing non-empty indices.

A shape containing a zero dimension represents a tensor with zero total elements. Therefore, there cannot be a valid non-empty flat index into that shape.

However, this edge case could make it into the coordinate computation performed by torch.unravel_index. Because the implementation relies on arithmetic involving the dimensions of the shape, a zero dimension could eventually result in a division or modulo-by-zero operation.

Instead of clearly communicating that the supplied indices were invalid for the requested shape, the operation could therefore fail with an unexpected runtime error.

The Fix

I added explicit validation for this case before the coordinate calculation takes place.

The resulting behavior distinguishes between two important cases:

Zero-sized shape + non-empty indices: The input is invalid and now raises a clear ValueError.
Zero-sized shape + empty indices: The operation remains valid and produces empty coordinate tensors.

Preserving the second case was important because an empty collection of indices does not attempt to reference an element that doesn't exist. It also maintains behavior consistent with NumPy for the corresponding edge case.

Reasoning Through the Edge Case

One of the most interesting parts of the contribution came during code review.

A question was raised about whether the validation should depend on all dimensions or whether the presence of any zero-sized dimension was sufficient to make non-empty indices invalid.

Working through the implementation made the answer clearer.

If any dimension of a tensor's shape is zero, then:

numel = shape[0] × shape[1] × ... × shape[n] = 0

The tensor therefore contains no elements.

Consequently, there is no valid flat index into that tensor, regardless of where the zero appears in its shape.

Tracing the implementation also required thinking through the coefficient calculations, broadcasting behavior, division, and modulo operations used to transform flat indices into multidimensional coordinates.

Testing

Along with the validation change, I added regression coverage for the edge case to ensure that invalid non-empty indices are rejected while the valid empty-index behavior continues to work correctly.

The change then went through PyTorch's upstream review and CI process before being approved and merged.

What I Learned

The code change itself is relatively small, but working in a production ML framework made the surrounding engineering particularly valuable.

I gained experience with:

Navigating a large open-source codebase like PyTorch
Understanding implementation details behind a familiar tensor API
Reasoning carefully about tensor shapes and zero-sized dimensions
Designing validation around API semantics rather than simply preventing a crash
Writing regression tests for unusual edge cases
Responding to technical feedback during upstream code review
Working through the contribution and CI process of a major open-source project

One of my biggest takeaways was that robustness in foundational libraries often comes from handling seemingly tiny edge cases correctly. When an API is used as widely as PyTorch, even input validation deserves careful consideration around semantics, compatibility, and existing behavior.

I'm excited to continue contributing to open source and exploring more of the systems and infrastructure behind machine learning.

Links

PyTorch PR #191092:
https://github.com/pytorch/pytorch/pull/191092

Technologies: Python · PyTorch · NumPy · Git · GitHub · Open Source · Testing

Proofdesk — The IDE for Open-Source Math Textbook Publishing

Harsha Raj Kumar — Thu, 23 Apr 2026 05:50:48 +0000

github
proofdesk

Inspiration

Math professors who write open-source textbooks are stuck in a painful loop: edit XML in a text editor → open a terminal → run a Docker build that takes 15 minutes → refresh a browser → realize one equation is wrong → repeat. There's no integrated workspace for it. Tools like Overleaf exist for LaTeX, but nothing exists for PreTeXt — the modern XML-based format used by university textbooks at Georgia Tech, MIT, and dozens of other institutions.

I'm a CS grad student at Vanderbilt. A professor in our math department showed me their workflow. I couldn't believe how broken it was for a format that produces genuinely beautiful output. So I built Proofdesk.

What it does

Proofdesk is a full-stack browser workspace that lets math professors write, build, preview, and publish PreTeXt textbooks without ever leaving their browser.

Write — Monaco editor (the engine behind VS Code) with PreTeXt XML syntax highlighting, full-text search across every file in the repository, and a LaTeX/PreTeXt snippet library for common blocks like theorems, definitions, and proofs.

Build — one click triggers the full PreTeXt → HTML pipeline inside a Docker container: TeX Live compiles LaTeX equations to PDF, fontforge extracts font metrics, Inkscape converts each equation to a crisp inline SVG. Every equation in the textbook renders as real vector math — not MathJax approximations.

Preview — a live side-by-side preview updates after each build. 31 interactive 3D visualizations built with MathBox.js (GPU-accelerated WebGL) let students explore eigenspaces, row reduction, orthogonal projection, and least-squares problems in real time.

Collaborate — WebSocket-powered real-time collaboration, in-browser terminal (node-pty + xterm.js), Git history browser, and one-click shareable preview links with a 7-day TTL. Send a draft chapter to a reviewer without them needing a GitHub account.

Publish — Export the entire built textbook as a self-contained ZIP. Deploy to any static host. No runtime dependencies.

How I built it

Frontend: React + TypeScript, Monaco editor, xterm.js, MathBox.js (WebGL), Playwright for E2E tests.

Backend: Node.js + Express, GitHub OAuth, WebSocket (ws), node-pty for real TTY terminal sessions, BullMQ + Redis for build job queuing, archiver for ZIP export.

Build pipeline: The hardest part. PreTeXt's toolchain was written for a specific era — Python 2, Ruby 2-era gems, Inkscape 0.9x CLI syntax, CoffeeScript 1.12.7, a custom SCons pipeline. I wrote a 720-line Docker build script that patches Python 2 idioms at build time without modifying the source repo permanently:

sed replaces unichr() → chr() across Python files
Rewrites the Inkscape inkscape_script() method for 1.x action syntax
Falls back from compass to sass-embedded when Ruby 3.2 rejects it
Patches SCons builder suffix declarations to fix cache-busting in the demo pipeline
Wraps git hash-object calls in try/except so missing intermediate files don't abort

The result: a fully reproducible Docker image that builds a 40-chapter math textbook with 750+ rendered equation SVGs from a completely unmodified upstream PreTeXt repo.

Infrastructure: EC2 t3.small, docker-compose, Nginx reverse proxy, DuckDNS, GitHub Actions for CI/CD with Playwright sanity tests on every deploy.

Challenges I ran into

The legacy dependency maze was the biggest one. The PreTeXt build toolchain spans four languages (Python, Ruby, CoffeeScript, XSL), three incompatible major versions of key tools, and a build system (SCons) that almost nobody uses anymore. Making all of this work reproducibly inside a modern Docker container on Ubuntu 24.04 required reverse-engineering error messages I had never seen before and patching code I didn't write.

The math rendering pipeline was non-trivial. Each equation takes a round-trip through pdflatex → fontforge → Inkscape before becoming an SVG. Getting fontforge to extract the right font metrics for the Charter typeface, and getting Inkscape 1.x to accept the rewritten CLI flags, took more debugging time than the entire React frontend.

Docker-in-Docker orchestration — the backend mounts the Docker socket and spawns isolated PreTeXt build containers on demand. Handling container lifecycle, cleanup on user disconnect, concurrent session limits, and OOM kills on a t3.small with 2GB RAM required careful resource management.

Localhost vs EC2 rendering differences — the deployed site has a text overlap bug I'm still actively debugging. My current theory is a Nginx MIME type misconfiguration for .woff2 font files causing the browser to fall back to a system font with different metrics. Working on it.

Accomplishments I'm proud of

A 720-line build orchestration script that makes a Python 2 / Ruby 2 / Inkscape 0.9x toolchain work on modern infrastructure with zero permanent source modifications
31 GPU-accelerated interactive math visualizations running in the browser via MathBox.js
A real TTY terminal session inside the browser using node-pty — same behavior as SSH, not a fake shell
Full Playwright E2E test suite including GitHub OAuth smoke tests and multi-browser sanity checks
A shareable preview link system that lets non-technical reviewers see a built textbook without any GitHub account

What I learned

Legacy compatibility is underrated as an engineering skill. The ability to make old code run on new infrastructure — without breaking the original — is something most CS programs don't teach but every production engineering team deals with constantly.

I also learned that the hardest bugs are the ones that only reproduce in production. The font rendering overlap on EC2 taught me that "it works on my machine" is not a deployment strategy, and that Nginx configuration deserves as much attention as application code.

What's next

Fix the EC2 font rendering bug (actively working)
Multi-textbook support — paste any PreTeXt GitHub URL and get a full workspace
Student mode — read-only workspace with a purpose-limited AI tutor that can answer questions about the material but cannot do homework
CRDT-based real-time collaboration for simultaneous multi-author editing
Incremental builds — only rebuild changed chapters, cutting build time from 15 min to under 2 min
LMS integration (Canvas, Blackboard) with SSO for institutional deployment

Built with

React TypeScript Node.js Express Docker Nginx Redis BullMQ Monaco Editor xterm.js MathBox.js WebGL node-pty Playwright GitHub OAuth AWS EC2 PreTeXt TeX Live Inkscape fontforge SCons Python Ruby CoffeeScript