DEV Community: TildAlice

Gymnasium Custom Environment: 7 Patterns That Save Hours

TildAlice — Fri, 10 Apr 2026 21:05:19 +0000

Why Most Custom Environments Break in Subtle Ways

Your custom Gymnasium environment passes check_env(), trains for 10k steps without errors, then crashes with a cryptic shape mismatch at step 47,293. Or worse — it trains fine but never converges, and you spend days tweaking PPO hyperparameters when the real bug is in your reset() method.

I've debugged dozens of custom environments over the past two years. The pattern is always the same: the obvious mistakes (wrong action space type, missing render() method) get caught immediately. The subtle ones — observation normalization inconsistencies, edge cases in step() transitions, incorrect terminal state handling — waste days of debugging and GPU time.

This post covers seven patterns that catch 90% of custom environment bugs before they reach training. Not the basics you'd find in the official Gymnasium tutorial, but the production patterns I wish I'd known earlier.

Photo by Google DeepMind on Pexels

Continue reading the full article on TildAlice

SAM vs Grounded-SAM: Zero-Shot Segmentation mIoU Gap

TildAlice — Fri, 10 Apr 2026 18:04:37 +0000

The Zero-Shot Segmentation Promise Falls Apart on Custom Data

Meta's Segment Anything Model (SAM) hit the scene with a bold claim: segment any object in any image with zero training. The original paper (Kirillov et al., 2023) showed stunning qualitative results. Then Grounded-SAM came along, combining SAM with open-vocabulary detection to enable text-prompted segmentation. Everyone assumed this was the solution for production pipelines that needed to segment arbitrary objects without annotation.

I ran both through a battery of tests on COCO val2017 and a custom industrial dataset. The results weren't what the papers promised.

SAM achieves 46.5 mIoU on COCO's 80 categories when you feed it ground-truth bounding boxes as prompts. That's decent. But the moment you swap COCO for custom objects—say, defects on PCB boards or specific machine parts—that number craters to around 28-32 mIoU depending on the object type. Grounded-SAM, which uses Grounding DINO (Liu et al., 2023) for detection before SAM segments, brings text-based prompting but introduces its own failure modes.

Continue reading the full article on TildAlice

yfinance to Polygon.io: 4 Breaking Changes in Migration

TildAlice — Fri, 10 Apr 2026 15:04:15 +0000

The Timezone Trap That Ate My Backtest

I spent two hours debugging phantom gains in a momentum strategy before realizing yfinance and Polygon.io handle market timestamps differently. yfinance returns datetime64[ns] with naive UTC timestamps. Polygon returns timezone-aware America/New_York timestamps. When you merge dataframes from both sources, pandas silently coerces them to a common timezone — and your bar alignment breaks.

This isn't just an annoyance. If you're migrating a production system that assumes all timestamps are UTC, every single join, resample, and lookback window needs adjustment.

Polygon.io's free tier gives you 5 API calls per minute and delayed data. The paid Basic tier ($29/month as of 2026) unlocks real-time bars and 100 calls/minute. For most retail algo strategies, that's enough. But if you're running high-frequency scans across 500+ tickers, you'll hit rate limits fast.

Here's what actually breaks when you swap the data source.

Photo by Chris F on Pexels

API Call Structure: From One-Liner to Explicit Parameters

Continue reading the full article on TildAlice

Pre-commit Ruff Locks: Pin to CI or Accept 2-Week Drift

TildAlice — Thu, 09 Apr 2026 21:04:23 +0000

Lock Ruff and Watch CI Break Three Weeks Later

Pinning Ruff to an exact version in your pre-commit config sounds responsible. It stops your local hooks from breaking when Ruff releases a new rule. But here's what actually happens: three weeks later, your CI runs a fresher Ruff version, flags violations your local setup missed, and now you're fixing "new" lint errors in code that passed pre-commit yesterday.

I've seen this exact pattern in a dozen repos using Ruff + pre-commit. The version drift window keeps growing—Ruff ships releases every 2-3 weeks, and the gap between your locked local hook and the latest CI check becomes a 6-8 week lag by the time someone notices. That's enough time for 3-4 new rules to land, meaning "passing" commits suddenly fail in CI.

The alternative—letting Ruff auto-update in pre-commit—means developers get surprise lint failures on git commit after a hook refresh. Both options feel broken, but one breaks locally (fixable before push), the other breaks in CI (blocks merges). Let's figure out which pain is worth taking.

Photo by cottonbro studio on Pexels

Continue reading the full article on TildAlice

TorchServe vs ONNX Runtime: First Inference in 5 Minutes

TildAlice — Thu, 09 Apr 2026 18:04:49 +0000

The 47ms Difference That Made Me Reconsider TorchServe

First inference on a ResNet-50 model: 62ms with ONNX Runtime, 109ms with TorchServe. That's almost 2x slower for TorchServe — but here's the thing, those numbers flip completely once you understand what each tool is actually optimizing for.

I ran these tests on an AWS t3.medium (2 vCPUs, 4GB RAM) because that's what most people actually have access to when prototyping. The gap narrows dramatically on GPU instances, but CPU-only deployments are still the reality for many teams shipping their first model.

Photo by rakhmat suwandi on Pexels

Why Setup Complexity Matters More Than You Think

TorchServe requires Java. That's the first surprise for Python developers expecting a pip-install-and-go experience. The model archiver, the configuration files, the handler classes — there's real infrastructure thinking baked in. ONNX Runtime? It's pip install onnxruntime and you're running inference in three lines.

Continue reading the full article on TildAlice

BERT vs DistilBERT vs TinyBERT: Speed-Accuracy Trade-offs

TildAlice — Thu, 09 Apr 2026 15:04:31 +0000

The 300MB Model That Runs in 40ms

BERT-base sits at 110M parameters and 440MB on disk. DistilBERT cuts that to 66M parameters and 260MB. TinyBERT goes further — 14.5M parameters, 55MB, and inference that actually runs on a Raspberry Pi without thermal throttling.

But here's the catch: you're not just shrinking the model. You're fundamentally changing how it encodes language. DistilBERT uses knowledge distillation, keeping the full 768-dimensional hidden states. TinyBERT applies distillation at every layer AND shrinks the hidden size to 312 dimensions. That architectural difference matters more than the parameter count suggests.

I'm comparing all three on a real-world task: sentiment classification on 50k IMDB reviews. The goal is to see where the accuracy drop actually hurts, and where it's just noise.

Photo by Berna Deniz on Pexels

BERT-base: The Baseline You're Probably Overpaying For

BERT-base (Devlin et al., 2019) uses 12 transformer layers, 768 hidden dimensions, and 12 attention heads. The attention mechanism computes:

Continue reading the full article on TildAlice

Hardware Wallet Security: 3 Attacks That Bypass the UI

TildAlice — Thu, 09 Apr 2026 08:11:38 +0000

Hardware Wallet Security: 3 Attacks That Bypass the UI

Hardware wallets promise "unhackable" private key storage. But that screen showing your transaction details? It's not always telling you the truth.

I tested three attack vectors against popular hardware wallets — address replacement, malicious firmware, and supply chain tampering. Two of them worked even when I verified addresses on the device screen. The third required physical access for under 90 seconds.

Here's what actually protects your crypto, and what's just security theater.

Photo by Morthy Jameson on Pexels

The Trusted Display Problem

Every hardware wallet tutorial tells you the same thing: "Always verify the address on the device screen before sending." Sound advice. Except it assumes the device is showing you accurate information.

Continue reading the full article on TildAlice

Hardware Wallet Architecture: BIP32/39/44 Chain Explained

TildAlice — Thu, 09 Apr 2026 08:02:17 +0000

The Signature That Shouldn't Have Worked

I was debugging a multi-sig wallet integration when I noticed something odd: the hardware wallet was signing transactions for addresses I never explicitly generated. The device had no network connection, yet it was correctly deriving child keys at arbitrary index paths like m/44'/60'/0'/0/42 without any prior setup.

That's when I realized I'd been fundamentally wrong about how these devices work. They're not storing a keyring — they're storing a single seed and computing everything on-demand using a deterministic tree structure defined by BIP32, BIP39, and BIP44.

This isn't just trivia. Understanding this architecture is a common interview filter for blockchain engineering roles, especially at exchanges, custody providers, or wallet teams. The question usually starts simple: "How does a hardware wallet generate addresses without storing them?" Then it escalates: "What happens if you lose the device but have your 12-word phrase?" or "Why can't you just brute-force a seed phrase?"

How Most People Get This Wrong

The naive mental model is that a hardware wallet is like a USB drive full of private keys. Generate an address? Store a new key. Sign a transaction? Look up the key from storage.

This breaks down immediately when you think about backup. If you're storing keys individually, your backup needs to grow every time you generate a new address. That's why hardware wallets don't work this way.

Continue reading the full article on TildAlice

Gradient Accumulation OOM: Hidden Memory Spike Explained

TildAlice — Wed, 08 Apr 2026 21:04:49 +0000

You Set batch_size=1, Enabled Gradient Accumulation, and It Still Crashes

Gradient accumulation is supposed to be the silver bullet for training large models on small GPUs. The pitch is simple: split a large batch into micro-batches, accumulate gradients across multiple forward passes, then update once. In theory, batch_size=1 with accumulation_steps=32 should use the same memory as batch_size=1 alone.

Except it doesn't. You enable gradient accumulation, drop the batch size to 1, hit Run, and watch CUDA OOM errors flood your terminal anyway. The GPU memory usage graph looks fine for the first few steps, then suddenly spikes and crashes at step 4 or 5.

This happened to me training a Vision Transformer (ViT-L/16) on a single RTX 3090 (24GB VRAM). Batch size 4 crashed. Batch size 2 crashed. Batch size 1 with accumulation_steps=4 still crashed. The model itself only needed ~8GB for weights and optimizer states. Where was the other 16GB going?

Photo by Codioful (formerly Gradienta) on Pexels

The Activations Nobody Warned You About

Continue reading the full article on TildAlice

Bitmask DP vs Backtracking for TSP: When $O(N^2 \cdot 2^N)$ Beats $O(N!)$

TildAlice — Wed, 08 Apr 2026 18:04:19 +0000

The Moment Backtracking Falls Apart

Backtracking solves TSP for 10 cities in 0.09 seconds. Bump that to 15 cities, and you're waiting 4+ seconds. Bitmask DP handles 15 cities in under 0.02 seconds — roughly 200x faster.

The algorithmic gap between these two approaches becomes a cliff once $N$ exceeds 12. I ran both implementations head-to-head on identical distance matrices, and the numbers don't lie. If you're prepping for coding interviews and think "I'll just use backtracking with pruning," this post might change your mind.

Why TSP Makes Interviewers Smile

The Traveling Salesman Problem shows up constantly in interviews disguised as other problems: minimum cost to visit all nodes, shortest hamiltonian path, optimal delivery route. The core is always the same — visit every vertex exactly once and minimize total cost.

The brute force complexity is $O(N!)$ which explodes hilariously fast. For $N=10$, that's 3.6 million permutations. For $N=15$, it's over 1.3 trillion. No amount of clever pruning saves you from factorial growth.

Bitmask DP drops this to $O(N^2 \cdot 2^N)$. For $N=15$, that's roughly 7.4 million operations. Still exponential, but polynomial in the exponent makes all the difference.

The Backtracking Baseline

Let's start with what most people reach for first. Here's a clean backtracking implementation with basic pruning:


python
import time
import random

def tsp_backtracking(dist):
    n = len(dist)
    if n == 0:
        return 0

---

*Continue reading the full article on [TildAlice](https://tildalice.io/bitmask-dp-vs-backtracking-tsp-benchmark/)*

f-strings vs % Formatting: When Old Syntax Wins 2.1x Speed

TildAlice — Tue, 07 Apr 2026 21:04:55 +0000

The Benchmark That Made Me Question Everything

Run this on Python 3.11 and watch what happens:

import timeit

# f-string version
def fstring_format():
    x = 42
    return f"Value: {x}"

# % formatting version
def percent_format():
    x = 42
    return "Value: %d" % x

print(f"f-string: {timeit.timeit(fstring_format, number=10_000_000):.3f}s")
print(f"% format: {timeit.timeit(percent_format, number=10_000_000):.3f}s")

On my machine (M1 MacBook, Python 3.11.7), f-strings take 0.847s while % formatting finishes in 0.401s. That's 2.1x faster for the "legacy" syntax.

Wait, what?

Every tutorial since PEP 498 (Python 3.6) has told us f-strings are faster. The official docs say they're "a way to embed expressions inside string literals, using a minimal syntax." Most benchmarks show f-strings crushing .format() and % formatting. So why does this simple case flip the script?

Photo by Ylanite Koppens on Pexels

Why f-strings Are Usually Faster (And When That Breaks)

Continue reading the full article on TildAlice

Pandas Interpolation Methods: 5 Techniques Benchmarked on Sensor Data

TildAlice — Tue, 07 Apr 2026 18:05:06 +0000

Linear Interpolation Silently Destroys Seasonality

Most tutorials tell you to call df.interpolate() and move on. That default linear method just cost me a 12% accuracy drop on a demand forecasting model — because linear interpolation flattens seasonal peaks into mush.

The data looked fine. No NaN warnings, shapes matched, the pipeline ran. But the downstream LSTM kept underperforming on validation. After hours of staring at loss curves, I plotted the actual vs. interpolated values for a single sensor. The weekend dips? Gone. The Monday morning spikes? Smoothed into gentle slopes. Linear interpolation had turned my sawtooth pattern into a lazy sine wave.

This post compares five interpolation methods on real-world sensor data with 15% missing values. I'll show you exactly what each method does to your data distribution — and which one preserved the statistical properties I actually needed.

Photo by ㅤ quang vinh ㅤ on Pexels

The Dataset: Industrial Temperature Sensors with Gaps

Continue reading the full article on TildAlice