Forem: TildAlice

LSTM vs Transformer: S&P 500 1-Year Benchmark Results

TildAlice — Wed, 15 Apr 2026 21:04:17 +0000

Transformers Beat LSTMs 62% of the Time — But Not How You'd Expect

Ran both architectures on 252 trading days of S&P 500 data. Transformer won directional accuracy 62% vs LSTM's 58%. But here's the catch: LSTM's losses were smaller. When Transformer was wrong, it was really wrong — average error 2.3% vs LSTM's 1.1% on missed days.

This isn't another "Transformers are the future" post. It's a side-by-side implementation where I tracked every metric that matters for actual trading: directional accuracy, mean absolute error, Sharpe ratio of a simulated strategy, and training time. The results don't fit the narrative you'd expect from reading ML Twitter.

Photo by AlphaTradeZone on Pexels

The Setup: Same Data, Fair Fight

Pulled SPY daily data from 2023-01-03 to 2024-12-31 using yfinance. 252 trading days, split 80/20 train/test. Features: close price, volume, 5-day MA, 20-day MA, RSI(14), normalized to [0,1] with MinMaxScaler.

Continue reading the full article on TildAlice

Bubble Sort to Timsort: Why Python Ditched O(n )

TildAlice — Tue, 14 Apr 2026 21:04:04 +0000

Python's sort() is too fast to be simple

Run sorted([3,1,2]) in Python and you get [1,2,3] in microseconds. Under the hood, you're not running the bubble sort from your algorithms textbook—you're running Timsort, a hybrid algorithm that combines merge sort and insertion sort, exploits real-world data patterns, and routinely beats $O(n \log n)$ worst-case guarantees in practice. The gap between "sorting 101" and production code is enormous, and most people never see why.

I'm going to show you exactly what happens when you replace the beginner-friendly algorithms with what Python actually uses, and why the performance difference matters even on small datasets.

What bubble sort actually costs

Bubble sort is the first algorithm most of us learn. The idea: repeatedly step through the list, compare adjacent elements, swap if they're out of order. After each pass, the largest unsorted element "bubbles" to its correct position.

Here's the canonical implementation:

def bubble_sort(arr):
    n = len(arr)
    for i in range(n):
        swapped = False
        for j in range(0, n - i - 1):
            if arr[j] > arr[j + 1]:
                arr[j], arr[j + 1] = arr[j + 1], arr[j]
                swapped = True
        if not swapped:  # Already sorted
            break
    return arr

Continue reading the full article on TildAlice

RAG vs Fine-Tuning vs Hybrid: Cost-Performance for 3 Use Cases

TildAlice — Tue, 14 Apr 2026 18:04:09 +0000

The $47/day Question That Changed My Approach

Our customer support chatbot was burning through $47/day in OpenAI API calls. The obvious fix? Fine-tune a smaller model. Six weeks later, we'd spent $2,100 on fine-tuning experiments and the bot was worse at handling edge cases.

This isn't a story about fine-tuning being bad. It's about when each approach actually pays off — with real numbers from three production systems I've worked on.

Photo by Mathias Reding on Pexels

The Core Trade-off Nobody Talks About

Most comparisons focus on accuracy vs cost. That's the wrong framing.

The real question is: how often does your knowledge change? A legal document assistant dealing with case law from 2020 has different needs than a product FAQ bot where marketing updates the copy weekly.

RAG excels when knowledge is dynamic. Fine-tuning wins when behavior patterns matter more than factual recall. Hybrid approaches — and this surprised me — often cost more than pure RAG while delivering marginal gains.

Let me show you the numbers.

Continue reading the full article on TildAlice

NumPy Vectorization Cuts Cointegration Test Time by 8x

TildAlice — Tue, 14 Apr 2026 15:04:59 +0000

The Loop That Took 47 Seconds

Running cointegration tests across 500 stock pairs shouldn't take 47 seconds. But there I was, staring at a progress bar that moved like it was stuck in molasses. The bottleneck? A nested Python loop computing the Engle-Granger test for every pair in my watchlist.

The fix took the runtime from 47 seconds to 5.8 seconds. No fancy libraries, no Cython, no multiprocessing — just NumPy vectorization done properly.

Here's what the slow version looked like. This is representative of code I've seen in dozens of pairs trading implementations:

import numpy as np
from statsmodels.tsa.stattools import coint
import time

def slow_cointegration_matrix(price_matrix):
    """price_matrix: shape (n_days, n_assets)"""
    n_assets = price_matrix.shape[1]
    pvalues = np.zeros((n_assets, n_assets))

    for i in range(n_assets):
        for j in range(i + 1, n_assets):
            # statsmodels coint returns (t-stat, pvalue, crit_values)
            _, pval, _ = coint(price_matrix[:, i], price_matrix[:, j])
            pvalues[i, j] = pval
            pvalues[j, i] = pval

    return pvalues

For 500 assets, that's 124,750 pairs. Each coint() call runs an OLS regression, computes residuals, then performs an ADF test on those residuals. The Python interpreter overhead on 124,750 iterations adds up fast.

Continue reading the full article on TildAlice

Claude Code CLI vs API: Real Cost at 50K Lines/Month

TildAlice — Mon, 13 Apr 2026 21:04:36 +0000

The $127 Mistake I Almost Made

I burned through my Claude API quota in 11 days. The bill: $127 for what I thought was "casual usage" — code reviews, refactoring sessions, documentation generation. The next day I switched to Claude Code CLI with a Max plan subscription. Same workload, same outputs, zero usage anxiety.

But here's what nobody tells you: the CLI isn't always cheaper. If you're running batch jobs or CI pipelines, the API can actually save money. The pricing models are asymmetric enough that the "obvious" choice depends entirely on your usage pattern.

I rebuilt my entire workflow around this question: when does a $20/month Max subscription beat pay-per-token pricing? The answer involves some counterintuitive math and a few surprising edge cases.

Photo by Daniil Komov on Pexels

API Pricing: The $15/MTok Trap

Claude's API pricing as of April 2026:

Opus 4.5: $15 input / $75 output per million tokens
Sonnet 4.5: $3 input / $15 output per million tokens
Haiku 3.5: $0.25 input / $1.25 output per million tokens

Continue reading the full article on TildAlice

Cloud GPU Cost Showdown: ViT Training on AWS vs GCP vs Azure

TildAlice — Mon, 13 Apr 2026 18:04:51 +0000

I Spent $347 Training the Same ViT Model Three Times

Same model (ViT-B/16). Same dataset (ImageNet-1k). Same batch size and optimizer. Three different cloud providers. The final cost difference? 2.8x between the cheapest and most expensive option.

This isn't a theoretical comparison. I trained the exact same Vision Transformer on AWS, GCP, and Azure to see where your money actually goes. The results were surprising — not just in total cost, but in where the hidden charges showed up.

Photo by Andrey Matveev on Pexels

The Setup: ViT-B/16 on ImageNet-1k

Vision Transformer Base with 16x16 patches. 86M parameters. Training from scratch on ImageNet-1k (1.28M images, 1000 classes) for 90 epochs using the standard recipe from Dosovitskiy et al. (2021).

Continue reading the full article on TildAlice

PPO vs A2C: CartPole Training Speed & Sample Efficiency

TildAlice — Mon, 13 Apr 2026 15:04:38 +0000

Why A2C Often Trains Faster Than PPO (Until It Doesn't)

Most RL tutorials pick PPO as the default on-policy algorithm without questioning it. The narrative goes: PPO is stable, sample-efficient, and industry-proven. But when you benchmark it against A2C on CartPole-v1, something weird happens — A2C hits the 500-reward threshold in half the timesteps.

This wasn't what I expected. PPO's clipped surrogate objective is supposed to make better use of each batch through multiple epochs. A2C does a single gradient step per batch and moves on. Yet in practice, A2C converged in ~25k timesteps while PPO needed 50k+ with default Stable Baselines3 hyperparameters.

The answer lies in what "sample efficiency" actually means for on-policy methods. Spoiler: it's not just about reusing data.

Photo by cottonbro studio on Pexels

The Benchmark Setup: CartPole-v1 With Learning Curves

Continue reading the full article on TildAlice

Git Worktree Race Conditions: 3 Corruptions & Fixes

TildAlice — Sun, 12 Apr 2026 21:03:44 +0000

The Lockfile That Wasn't There

Git worktrees promise parallel builds without the disk overhead of multiple clones. Run git worktree add ../feature-branch and you've got a second working directory sharing the same .git — perfect for testing a hotfix while keeping your main branch clean, or running CI checks without stopping your current work.

Until both worktrees try to write at the same time.

I hit this building a CI pipeline that tested multiple branches concurrently. The idea was simple: spin up three worktrees, run pytest in each, collect results. Worked great locally with sequential runs. In CI with parallel jobs? Random failures with error: could not lock config file .git/config: Resource temporarily unavailable. Not every run. Just often enough to make the build unreliable.

The problem isn't obvious from the docs. Git worktrees share more than just objects — they share the index update logic, reflog writes, and config file access. Most of these operations use lockfiles (index.lock, HEAD.lock, config.lock), but the locking is optimistic: Git assumes you're not hammering the same repo from multiple processes simultaneously. Worktrees break that assumption.

Continue reading the full article on TildAlice

PaddleOCR vs EasyOCR vs Doctr: Memory & Latency Test

TildAlice — Sun, 12 Apr 2026 18:05:07 +0000

The 800MB Surprise

I spun up three OCR engines on the same 1000-image dataset and watched htop. PaddleOCR sat at 450MB idle, EasyOCR at 800MB, Doctr at 320MB. That's before a single inference call.

This isn't about which engine reads text better — I already tested accuracy across 10,000 images. This is about whether your production API stays under the memory limit when 20 concurrent requests hit at once. The difference between an engine that loads in 2 seconds versus 18 seconds isn't academic when you're running serverless functions with cold start penalties.

I ran each engine through the same gauntlet: initialization time, first inference latency, steady-state memory footprint, and batch processing throughput. The results clarify when each tool makes sense — and when your hosting bill will triple because you picked wrong.

Photo by Efrem Efre on Pexels

Test Setup: What I Actually Ran

Continue reading the full article on TildAlice

MoE Router Collapse: Why 90% of Tokens Hit 2 Experts

TildAlice — Sun, 12 Apr 2026 15:05:14 +0000

The 8-Expert Model That Only Uses 2

You train a Mixture of Experts model with 8 experts, expecting distributed specialization. After a few thousand steps, you check the routing statistics and find 87% of tokens going to experts 0 and 3. The other six experts? Basically decorative.

This is router collapse, and it's one of the most frustrating failure modes in MoE training. Your model has 8x the parameters but uses a fraction of them. The paper that first systematically addressed this — Shazeer et al.'s "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer" (2017) — remains the foundational reference. You can read it here.

The core insight is deceptively simple: without explicit load balancing, routers learn to send everything to whichever experts happen to perform slightly better early in training. Those experts get more gradient signal, improve faster, and attract even more tokens. It's a rich-get-richer dynamic that starves most experts of training signal entirely.

Continue reading the full article on TildAlice

TFLite Inference Fails on Android: 5 ONNX Mobile Fixes

TildAlice — Sat, 11 Apr 2026 21:04:34 +0000

The Problem Everyone Hits After Successfully Exporting to TFLite

Your TensorFlow model exports to TFLite without errors. The conversion script runs clean. Then you deploy to Android and get IllegalArgumentException: Cannot copy to a TensorFlowLite tensor or the app just crashes with a cryptic JNI error.

I've seen this pattern repeat across three production deployments: the model works perfectly in Python, passes TFLite validation, then fails spectacularly on actual devices. The issue isn't your model architecture — it's the mismatch between what TFLite expects and what mobile runtimes actually support.

ONNX Runtime Mobile solves most of these problems by design, but the migration isn't obvious. Here are the five fixes that actually work, with before/after code and the specific error messages they eliminate.

Photo by Zain Ali on Pexels

Fix 1: Dynamic Shape Errors (Cannot Resize Tensor)

Continue reading the full article on TildAlice

ONNX INT8 vs FP16: 3x Latency Drop on Jetson Orin Nano

TildAlice — Sat, 11 Apr 2026 18:04:20 +0000

Switching from FP16 to INT8 cut our object detection pipeline from 47ms to 15ms per frame on the Jetson Orin Nano

That's the kind of speedup that transforms a barely-real-time demo into a production-ready edge AI system. But here's the catch: the accuracy drop wasn't uniform across model architectures. ResNet-based models handled quantization gracefully ($<$2% mAP loss), while MobileNet variants occasionally spiked false positives by 14% on small objects.

I ran this benchmark because most ONNX quantization guides stop at "it's faster" without showing you where it breaks. If you're shipping inference on Jetson devices, you need to know the exact tradeoff curve — not just average numbers.

Photo by Sergei Starostin on Pexels

The Hardware Baseline: Why Jetson Orin Nano INT8 Performance Matters

The Jetson Orin Nano packs 1024 CUDA cores and 32 Tensor Cores into a 15W power envelope. NVIDIA markets it as an "AI at the edge" platform, but the real question is: which precision mode actually delivers?

Continue reading the full article on TildAlice