I build optimization algorithms and research tooling for quantitative finance, from Palo Alto and Abu Dhabi.

I left continental Europe in 2004 to become a Rhodes Scholar at Balliol College, Oxford. I wrote my DPhil — Oxford's PhD — on fast matrix functions, supervised by Nick Trefethen. Shadows of this past include

• nncg — non-negative conjugate gradients: bound-constrained SPD quadratics solved by a guarded active-set loop, the reference implementation for Schmelzer & Stoll
• mean_variance_solvers — two companion working papers on fast matrix-free and direct solvers for long-only mean-variance portfolios

In 2007 I jumped head first into quantitative hedge funds, where I became interested in higher-dimensional convex problems

• linalg — the linear algebra underneath portfolio optimization
• cvxcla — the critical line algorithm: exact efficient frontiers rather than sampled ones
• pyhrp — cluster-based allocation: hierarchical risk parity, Schur complement risk parity, 1/N

I have released utilities such as

• jquantstats — time series and portfolio analytics
• basanos — a first hurdle for expected returns

Entire strategies are discussed in

• cs — the 10-line CTA: a trend-following strategy in ten lines of code, and what convex programming reveals about its Sharpe ratio, kurtosis and trading costs. Written for a talk at Credit Suisse, on a challenge from a young CEO. The engine underneath it is TinyCTA

In 2023 I was a visiting scholar at Stanford, working with Stephen Boyd. That is where the cvxgrp work comes from: cvxcla above, and alongside it simulator for backtests small enough to read, cvxrisk for risk models you can compose, and cvxball for the smallest enclosing sphere.

In 2025 I launched — together with HE Omar Saif Ghobash — Jebel Quant Research. Jebel Quant Research offers help with data, strategies and trading. We also continue the tradition of publishing open source software. We have released

• rhiza — one template repository that owns the boring parts of a Python project: CI workflows, the Makefile, linting, typing, test and coverage gates, and the docs build. A repo pins a template release and syncs; every project then shares one configuration instead of drifting into its own.
• rhiza-claude — the same workflow as slash commands for Claude Code: /init to adopt rhiza, /update to move to a newer template release, /quality to score a repo against the gates, /release to cut a version.

The point of both is leverage. Configuration is written once, reviewed once, and then inherited — so the time goes into the research and not into the plumbing.

I have had exposure to ADIA's Team Q. That experience became my manifesto:

A Technology Vision for Quantitative Trading — fourteen pages arguing that the industry's problems are organisational rather than technical. The handover model, in which research is written in Python and reimplemented in C++, produces diffuse accountability, dozens of reinvented wheels, and reconciliation as an organising principle; what replaces it is a single environment for research and production, a checkerboard team instead of an upstream and a downstream one, and quality at every stage instead of inspection at the end. Before any of the quant work I trained as a mechanic at AUDI, so the factory analogies come from the shop floor rather than a business book: the industry adopted Ford's assembly line, which manufacturing itself had largely abandoned by the 1980s, when Toyota's line is the better model and a professional kitchen — calm, deliberate, every station visible to every other — is better still. A chef buys the oven and does not cook from a packet. Knowing which is which is the whole of build-or-buy.

I am a firm believer in good and detailed documentation

• rhiza-education — training for and with rhiza
• An introduction to rhiza-claude — a paper on what the plugin is for, before what it contains: the two-repository boundary a sync respects, what "rhiza-managed" means on disk, the order the commands are meant to be run in, and why a tool that sells determinism keeps half of itself in prose

A good part of my work lands in other people's repositories — nearly 400 merged pull requests outside my own projects. The ones I keep returning to

• chebpy — a Python implementation of Chebfun, and so the most direct continuation of the DPhil I could have hoped for
• loman — computation graphs for quantitative research and trading
• investment-funnel — an open platform for developing and backtesting investment strategies
• pycharting — high-performance charting for financial data

And smaller fixes, usually filed where a tool got in my way: scipy, cvxpy, marimo, PyPortfolioOpt, Clarabel, Kaleido, finmarketpy, connector-x, ISLP labs.

I am currently one of the most active GitHub users in the UAE:

Though that is a measure of volume, and volume was never the point. Or maybe it was?

A more useful measure is what is still open. The table is regenerated nightly, so a new project joins it on its first release without anyone editing this file; the badges within it are live, and each one links to the thing behind it. The state of the work is as visible to you as it is to me.

	quality	coverage	downloads	issues	pull requests	branches	releases	latest	last commit
rhiza-claude		—	—			2	8
shrinkage	—	—	—			1	1
proximal	—	—	—			2	43
jquantstats		100%				2	68
basanos		100%				3	21
pyhrp		100%				1	140
cvxcla	—	100%				6	39
cvxrisk	—	100%				1	35
linalg		100%				1	19
nncg	—	100%	—			1	10
rhiza-hooks		100%	—			1	18
cs		—	—			3	13
TinyCTA		100%				2	77
jsharpe		100%				2	17
rhiza		—	—			3	106
mean_variance_solvers	—	—	—			3	2
rhiza-education	—	—	—			2	1

An issue that has been open for a year is not a backlog item, it is a decision that was never made.