Mastering Regular Expressions: A Deep Dive into LeetCode 10 with Dynamic Programming

Hey there, fellow coders! 👋 Are you ready to tackle one of LeetCode’s classic challenges that might seem daunting at first glance but becomes quite elegant with the right approach? Today, we’re diving into Problem 10: Regular Expression Matching.

This problem is a fantastic way to sharpen your dynamic programming (DP) skills and gain a deeper understanding of how regular expressions actually work under the hood. Don’t worry if regex feels like magic – we’re going to demystify it together!

The Puzzle: Regular Expression Matching

We’re given two strings: an input string s and a pattern p. Our goal is to determine if the pattern p completely matches the input string s.

The twist? The pattern p isn’t just plain text. It can contain two special characters:

• '.': This dot matches any single character. Think of it as a wildcard for one character.
• '*': This asterisk matches zero or more of the preceding element. This is where things get interesting!

Important Note: The match must cover the entire input string s, not just a part of it.

Let’s look at a few examples to solidify our understanding:

Example 1: Basic Mismatch

• s = "aa", p = "a"
• Output: false
• Why? The pattern “a” only matches the first ‘a’ of “aa”. It doesn’t cover the entire string.

Example 2: The Power of *

• s = "aa", p = "a*"
• Output: true
• Why? * means “zero or more of the preceding element,” which is ‘a’. By repeating ‘a’ once, the pattern becomes “aa”, matching the input. If s was “a”, it would also match (zero repetitions). If s was “aaa”, it would match (two repetitions).

Example 3: .* – The Ultimate Wildcard Combo

• s = "ab", p = ".*"
• Output: true
• Why? . matches any single character. * means “zero or more” of whatever precedes it. So, .* means “zero or more of any character.” It can match “ab”, “a”, “”, “xyz”, anything!

The “Aha!” Moment: Intuition

When you see problems involving matching parts of strings, especially with wildcards or options like “zero or more,” your mind should start thinking about Dynamic Programming (DP). Why DP? Because the decision at any point (does s[i] match p[j]) often depends on the results of smaller subproblems.

Imagine trying to match s and p.

• If p[j] is a regular character or . you just check if s[i] matches p[j] and then move on to matching the rest of s and p.
• But what if p[j] is *? This is the tricky part. * gives us options:
  1. It could match zero occurrences of the character before it.
  2. It could match one or more occurrences of the character before it.

These multiple choices, and the fact that we can build up a solution from smaller matches, strongly hints at DP!

Our Strategy: Dynamic Programming Grid

We’ll use a 2D boolean array, let’s call it dp, where dp[i][j] will be True if the first i characters of s (i.e., s[0...i-1]) match the first j characters of p (i.e., p[0...j-1]). Otherwise, it will be False.

Let m be the length of s and n be the length of p. Our dp table will be (m+1) x (n+1).

Step 1: Initialize the DP Table

• dp[0][0] = True: An empty string (s with 0 characters) always matches an empty pattern (p with 0 characters). This is our base case.

• First Row (dp[0][j] for j > 0): This represents matching an empty string s with a non-empty pattern p.
  An empty string can only be matched by a pattern that allows zero characters. This typically happens with *.
  If p[j-1] is '*', then it can match zero of the preceding element (p[j-2]). In this scenario, dp[0][j] would be True if dp[0][j-2] was True. All other dp[0][j] would be False.

Step 2: Fill the DP Table

We’ll iterate through s (from i = 1 to m) and p (from j = 1 to n) to fill the table. For each dp[i][j], we consider two main scenarios for the current character p[j-1]:

Scenario 1: p[j-1] is NOT '*' (i.e., it’s a regular character or '.')

• If p[j-1] matches s[i-1] (meaning p[j-1] == s[i-1] or p[j-1] == '.'), then s[0...i-1] matches p[0...j-1] only if s[0...i-2] matched p[0...j-2].
• So, dp[i][j] = dp[i-1][j-1].
• Otherwise (if p[j-1] doesn’t match s[i-1]), dp[i][j] = False.

Scenario 2: p[j-1] IS '*'

This is the trickiest part. The * implies “zero or more” of the preceding character (p[j-2]). Let’s call this preceding character prev_char_in_pattern = p[j-2].

We have two possibilities for how * can be interpreted:

1. * matches zero occurrences of prev_char_in_pattern:

   • In this case, prev_char_in_pattern and the * effectively disappear from the pattern.
   • So, we need to check if s[0...i-1] matches p[0...j-3]. This state is represented by dp[i][j-2].
   • Thus, dp[i][j] = dp[i][j-2].

2. * matches one or more occurrences of prev_char_in_pattern:

   • For * to match one or more times, prev_char_in_pattern must match the current character s[i-1]. (i.e., prev_char_in_pattern == s[i-1] or prev_char_in_pattern == '.').
   • If they match, s[i-1] is consumed by one instance of prev_char_in_pattern. We then need s[0...i-2] to match p[0...j-1] (the prev_char_in_pattern followed by * is still active, potentially matching more characters).
   • This state is represented by dp[i-1][j].
   • So, if prev_char_in_pattern matches s[i-1], then dp[i][j] can also be dp[i-1][j].

• Combining these: dp[i][j] will be True if either of these conditions holds.
  dp[i][j] = dp[i][j-2] (zero occurrences)
  If prev_char_in_pattern matches s[i-1] (i.e., p[j-2] == s[i-1] or p[j-2] == '.'):
  dp[i][j] = dp[i][j] or dp[i-1][j] (one or more occurrences)

Step 3: The Result

After filling the entire dp table, the final answer will be in dp[m][n].

Let’s walk through an example: s = "aab", p = "c*a*b"

• dp[0][0] is T.
• dp[0][2] (for c*): p[1] is *, so dp[0][2] = dp[0][0] which is T. (empty string matches c* by c repeating 0 times).
• dp[0][4] (for c*a*): p[3] is *, so dp[0][4] = dp[0][2] which is T. (empty string matches c*a* by a repeating 0 times).
• Now, consider dp[1][1] (s="a", p="c"): p[0] (‘c’) != s[0] (‘a’). So F.
• Consider dp[1][4] (s="a", p="c*a*"):
  • p[3] is *. Preceding char p[2] is ‘a’.
  • dp[1][2] (zero ‘a’s for a*) is F.
  • Does p[2] (‘a’) match s[0] (‘a’)? Yes!
  • dp[0][4] (one or more ‘a’s) is T.
  • So dp[1][4] becomes F OR T = T.
• Finally, dp[3][6] will be T.

The Code

class Solution(object):
    def isMatch(self, s, p):
        """
        :type s: str
        :type p: str
        :rtype: bool
        """
        m, n = len(s), len(p)

        # dp[i][j] will be True if s[0...i-1] matches p[0...j-1]
        # Dimensions: (m+1) x (n+1)
        dp = [[False] * (n + 1) for _ in range(m + 1)]

        # Base case: Empty string matches empty pattern
        dp[0][0] = True

        # Initialize the first row (s is empty)
        # An empty string 's' can only match patterns like "a*", "a*b*", etc.
        # This means the pattern must end with '*' and its preceding element can be skipped.
        for j in range(1, n + 1):
            if p[j - 1] == '*':
                # If p[j-1] is '*', it means zero occurrences of p[j-2].
                # So, dp[0][j] depends on whether p[0...j-3] matched an empty string.
                dp[0][j] = dp[0][j - 2]

        # Fill the DP table for all other cells
        for i in range(1, m + 1):
            for j in range(1, n + 1):
                # Scenario 1: Current pattern character is a regular character or '.'
                # (p[j-1] is not '*')
                if p[j - 1] == s[i - 1] or p[j - 1] == '.':
                    # If current characters match, depend on the match of preceding substrings
                    dp[i][j] = dp[i - 1][j - 1]

                # Scenario 2: Current pattern character is '*'
                elif p[j - 1] == '*':
                    # Case A: '*' matches zero occurrences of the preceding element (p[j-2])
                    # We effectively ignore p[j-2] and p[j-1] (the '*')
                    # So, s[0...i-1] must match p[0...j-3]
                    dp[i][j] = dp[i][j - 2]

                    # Case B: '*' matches one or more occurrences of the preceding element (p[j-2])
                    # This is only possible if the preceding character (p[j-2]) matches s[i-1]
                    # (p[j-2] == s[i-1] or p[j-2] == '.')
                    if p[j - 2] == s[i - 1] or p[j - 2] == '.':
                        # If they match, '*' consumes s[i-1], and we check if s[0...i-2] matches p[0...j-1]
                        # (where p[j-1] is still '*', allowing it to match further characters)
                        dp[i][j] = dp[i][j] or dp[i - 1][j]

        return dp[m][n]

Time and Space Complexity Analysis

• Time Complexity: O(m * n)

  • We are filling an m x n DP table. Each cell calculation takes constant time (a few comparisons and assignments). Therefore, the total time complexity is proportional to the product of the lengths of the string s and pattern p.

• Space Complexity: O(m * n)

  • We use a 2D dp array of size (m+1) x (n+1) to store our intermediate results. This contributes O(m * n) to the space complexity.

Given the constraints 1 <= s.length <= 20 and 1 <= p.length <= 20, an O(m*n) solution is perfectly efficient for this problem. 20 * 20 = 400 operations per test case is lightning fast!

Key Takeaways

1. Dynamic Programming for String Matching: Problems involving matching substrings, especially with wildcards or varying length matches, are prime candidates for DP.
2. Defining DP State: Clearly defining dp[i][j] as the match for prefixes s[0...i-1] and p[0...j-1] is crucial.
3. Handling Special Characters (. and *):
   • . is straightforward: it matches any single character.
   • * requires careful consideration: it has two main interpretations (“zero occurrences” OR “one or more occurrences”) that lead to combining results from different DP states.
     • Zero occurrences: The * and its preceding character are skipped (dp[i][j-2]).
     • One or more occurrences: The * matches the current character s[i-1] (if the preceding char allows it), and the * pattern remains active (dp[i-1][j]).
4. Base Cases: Correctly initializing dp[0][0] and the first row (dp[0][j]) for an empty string s is vital for the DP to propagate correctly.

This problem is a fantastic way to stretch your DP muscles and see how complex string operations can be broken down into manageable subproblems. Keep practicing, and you’ll master these patterns in no time!

Published by p1Hzd8mRM8 on 2026-05-21 16:52:13

Geolocation questions come up regularly when operators start leasing IPv4 blocks. Does the subnet show up in the right country? How long until databases reflect the correct location? What’s the fix if something is wrong?

The short answer: for most infrastructure workloads, geolocation is irrelevant. For a specific set of use cases, it requires deliberate setup. This post covers both.

Two Separate Systems Worth Distinguishing

“Geolocation” in the IPv4 context actually refers to two different things, and confusing them leads to wasted troubleshooting time.

RIR-registered location – what’s recorded in the RIPE database via the geofeed: and geoloc: attributes on your inetnum object.

Commercial database location – what services like MaxMind, IPinfo, or Google display when they query your block. These databases pull from multiple signals:
RIR records, BGP routing data, latency measurements, user corrections. They operate independently and update on their own schedules.

When operators ask whether their subnet will appear as a specific country, they’re almost always asking about the second category. The answer depends on which database, when it last crawled your block, and what signals it weighted.

RIPE Attributes: What Actually Works

Three attributes are relevant here, and they’re not equally useful.

geofeed: – links to a structured CSV file (RFC 8805 format) hosted at a public HTTPS URL. Providers supporting RFC 9632 discovery ingest it automatically.

This is the mechanism with real adoption among commercial database providers and the recommended starting point.

geoloc: – records latitude/longitude coordinates directly in the RIPE database. Limited adoption among third-party providers. Worth setting, but don’t rely on it to influence MaxMind or similar databases.

country: – an administrative registration field. RIPE’s own documentation notes it was never formally specified what this field represents. Not a geolocation signal. Don’t treat it as one.

RIPE doesn’t verify any of this data. Publishing a correctly configured geofeed gives providers a structured, crawlable source – but each provider acts on it according to their own update cycle.

Use Cases Where Geolocation Is Operationally Critical

VPN and proxy services – if you’re selling a country-specific endpoint, the IP block needs to register as that country in the databases your users’ apps query.

Programmatic advertising – ad exchanges categorize traffic geographically. European inventory carries different pricing from traffic that appears to originate outside the EU. Miscategorized geolocation means mispriced inventory.

CDN configuration – routing decisions are based on IP location. A subnet appearing in the wrong region routes users to suboptimal edge nodes.

GDPR and data localization compliance – infrastructure processing EU data sometimes needs to be clearly identifiable as EU-based. An IP block appearing outside the EU creates compliance friction regardless of where the servers physically sit.

Web scraping and data collection – many platforms serve differentiated content, pricing, and availability by detected country. Your IP’s geolocation determines the geographic view your infrastructure gets.

Use Cases Where It Doesn’t Matter

General hosting, application servers, ISP infrastructure, internal networking, standard web traffic delivery – geolocation has no operational effect on any of it.

BGP routing operates on routing tables. Email deliverability depends on reputation signals – spam history, blacklist status, authentication records – not on geolocation.
A subnet geolocated in Amsterdam and one geolocated in Paris are treated identically by receiving mail servers.

Propagation Timelines

After lease activation, there’s a normal window before all databases reflect the correct location.

MaxMind – the most widely used commercial database – updates the majority of its GeoIP databases every weekday. Correction requests via the GeoIP Exchange program (where geofeed submission is now the standard method) don’t come with a committed review timeline.

Downstream services – CDN networks, ad exchange databases, streaming platform geolocation layers – typically take two to six weeks to fully propagate a change.

This is expected behavior, not a problem to solve.

If your deployment is geolocation-sensitive, build in a one-to-two week buffer after activation before relying on correct location data in production. For ad tech or CDN-critical workloads, two to four weeks is the safer margin.

Geolocation vs. Reputation: Not the Same Thing

These get conflated more than any other pair of concepts in IPv4 operations.

Geolocation – where your block appears to be located.
Reputation – the behavioral history associated with that block: spam records, blacklist entries, abuse flags.

Completely separate systems. A block can have accurate geolocation and a problematic reputation record, or an outdated geolocation entry and a perfectly clean history. Correcting one has no effect on the other.

If you’re evaluating a subnet before leasing, run a reputation check. Not a geolocation lookup.

For a more detailed breakdown of how this applies to IPv4 leasing specifically, including how IPbnb handles geolocation validation at the listing stage, the full guide is on our blog: IPv4 Geolocation and Leasing – IPbnb

The Problem We Were Actually Solving

Our platform store integration used a popular crypto payment gateway, which claimed to support over 150 cryptocurrencies. However, the actual support varied greatly depending on the country of the customer. For instance, users in the United States could receive payouts in their preferred currency within hours, while those in South Africa or India were stuck with a 7-10 day delay. We were losing customers due to these inconsistent payout timelines, and our business was suffering as a result.

What We Tried First (And Why It Failed)

Initially, we attempted to optimize our existing integration to improve the payout timelines. We added retry mechanisms, optimized network requests, and even implemented a queue-based system to process payments asynchronously. However, despite these efforts, the issue persisted. We realized that the root cause lay not with our implementation, but with the payment gateway’s architecture.

The Architecture Decision

We decided to take a radical approach and automate our order fulfillment directly with the blockchain. Instead of relying on the payment gateway, we would create our own smart contracts to handle payments and transfers. This would give us complete control over the payout process, allowing us to respond to customer requests in real-time. We knew it wouldn’t be an easy task, but we were willing to take the risk.

What The Numbers Said After

After implementing our new system, we saw a significant improvement in payout timelines. The median payout time reduced from 24 hours to just 1 hour for US customers, and to 3 hours for international customers. Our customers were finally able to receive their payouts in a timely manner, reducing frustration and increasing overall satisfaction. We also noticed a significant increase in customer retention, with a 25% reduction in churn rates.

What I Would Do Differently

In retrospect, I would recommend a more gradual approach to automating order fulfillment. While our radical change worked, it introduced a new set of challenges, such as higher development and maintenance costs. I would suggest starting with small-scale pilots to validate the new architecture before scaling up. By doing so, we could have mitigated some of the risks and ensure a smoother transition for our customers. Nonetheless, the lessons learned from this experience have been invaluable, and we continue to refine our system to accommodate the evolving needs of our customers.

You can’t ship htdemucs_ft on iOS. You can’t ship it on Android. You can’t run it in a browser. PyTorch Mobile is a 2 GB install and a permission to break, MLX needs Apple Silicon, and the obvious answer — ONNX — has been “broken on htdemucs” across four open GitHub issues for three years.

I just shipped the first working ONNX export of htdemucs_ft. It runs in onnxruntime, is 1.31× faster than PyTorch on CPU, and is numerically equivalent to the original (max absolute difference: 0.000163 on drums, 0.000008 on vocals). All four specialist sub-models are on Hugging Face: StemSplitio/htdemucs-ft-onnx.

This is the engineering writeup — the 4 blockers that killed every prior attempt and the patches that beat them.

What You’ll Learn

• ✅ Why htdemucs is so hard to export (complex tensors, Python dynamism, fused C++ kernels)
• ✅ How to replace torch.stft with Conv1d without losing accuracy (5 × 10⁻⁶ round-trip diff)
• ✅ How to patch fractions.Fraction, random.randrange, and aten::_native_multi_head_attention
• ✅ How to verify parity to 4 decimals before trusting the export
• ✅ Pure numpy + onnxruntime inference — no PyTorch at runtime

Prerequisites

pip install "torch>=2.4,<2.5" "torchaudio>=2.4,<2.5" demucs onnx onnxruntime numpy soundfile

No GPU required for export or inference. Tested on Apple M4 Pro and Linux x86_64. If you don’t have demucs set up yet, follow the complete demucs local setup guide first.

Why doesn’t htdemucs export to ONNX out of the box?

Short answer: Because the model uses four PyTorch features that no ONNX exporter has good answers for — complex tensors in the STFT, fractions.Fraction arithmetic in model.segment, random.randrange inside the cross-transformer, and the fused C++ aten::_native_multi_head_attention kernel.

Each one stops torch.onnx.export and torch.onnx.dynamo_export cold. You hit them in order; each new patch unblocks the next failure.

Blocker 1: complex64 STFT output

Short answer: Replace torch.stft with a Conv1d using sin/cos kernels that emit two real-valued channels.

The first op in HT-Demucs is:

z = torch.stft(x, n_fft=4096, hop_length=1024, window=hann,
               win_length=4096, normalized=True, center=True,
               return_complex=True, pad_mode="reflect")

return_complex=True returns a complex64 tensor. ONNX’s STFT op (opset 17+) does not support complex outputs; every downstream slice/transpose fails. The workaround:

import math, torch
import torch.nn as nn
import torch.nn.functional as F

def _make_stft_kernels(n_fft: int):
    n = torch.arange(n_fft, dtype=torch.float64)
    window = torch.hann_window(n_fft, periodic=True, dtype=torch.float64)
    norm = 1.0 / math.sqrt(n_fft)
    k = torch.arange(n_fft // 2 + 1, dtype=torch.float64).unsqueeze(1)
    angles = 2 * math.pi * k * n.unsqueeze(0) / n_fft
    cos = (window * torch.cos(angles)) * norm
    sin = (window * -torch.sin(angles)) * norm   # negative for forward STFT
    return cos.float().unsqueeze(1), sin.float().unsqueeze(1)

class RealSTFT(nn.Module):
    def __init__(self, n_fft=4096, hop_length=1024):
        super().__init__()
        cos, sin = _make_stft_kernels(n_fft)
        self.register_buffer("cos_kernel", cos)
        self.register_buffer("sin_kernel", sin)
        self.n_fft, self.hop_length = n_fft, hop_length

    def forward(self, x):
        x = F.pad(x.reshape(-1, 1, x.shape[-1]),
                  (self.n_fft // 2,) * 2, mode="reflect")
        real = F.conv1d(x, self.cos_kernel, stride=self.hop_length)
        imag = F.conv1d(x, self.sin_kernel, stride=self.hop_length)
        return torch.stack([real, imag], dim=1)    # (BN, 2, F, T) real

Verify against the real thing before going further:

x = torch.randn(1, 343980)
ref = torch.stft(x, n_fft=4096, hop_length=1024,
                 window=torch.hann_window(4096), win_length=4096,
                 normalized=True, center=True, return_complex=True,
                 pad_mode="reflect")
ref_real = torch.stack([ref.real, ref.imag], dim=1)

stft = RealSTFT()
out = stft(x).squeeze(0)
print("max abs diff:", (out - ref_real).abs().max().item())   # ~5e-6

5 × 10⁻⁶ is rounding noise. Use the same trick (ConvTranspose1d with conjugate kernels + overlap-add window-squared envelope) for the inverse STFT. Now every view_as_real / view_as_complex in the model’s _magnitude and _mask methods can be rewritten to thread real-channel tensors through the whole forward pass.

Blocker 2: fractions.Fraction in model.segment

Short answer: Coerce to float before exporting.

Pretrained htdemucs_ft ships with model.segment = Fraction(39, 5) (= 7.8 seconds). Dynamo dies:

torch._dynamo.exc.Unsupported: call_function
UserDefinedClassVariable(<class 'fractions.Fraction'>)

Fix:

from fractions import Fraction

if isinstance(model.segment, Fraction):
    model.segment = float(model.segment)   # 7.8

Mathematically identical at inference. Trivial — but you don’t get to the next blocker without it.

Blocker 3: random.randrange in the cross-transformer

Short answer: Monkey-patch the affected method to hardcode shift=0.

CrossTransformerEncoder._get_pos_embedding calls Python’s random:

shift = random.randrange(self.sin_random_shift + 1)

At inference, sin_random_shift = 0, so random.randrange(1) always returns 0 — a no-op. But neither exporter can see through random and both bail out. Patch the method directly:

import types
from demucs.transformer import CrossTransformerEncoder, create_sin_embedding

def _get_pos_embedding_no_random(self_, T, B, C, device):
    if self_.emb == "sin":
        return create_sin_embedding(T, C, shift=0, device=device,
                                    max_period=self_.max_period)
    raise RuntimeError(f"emb={self_.emb} not handled at export")

for m in model.modules():
    if isinstance(m, CrossTransformerEncoder):
        m._get_pos_embedding = types.MethodType(_get_pos_embedding_no_random, m)

Blocker 4: aten::_native_multi_head_attention

Short answer: Replace nn.MultiheadAttention.forward with a plain Linear/bmm/softmax implementation.

Modern PyTorch short-circuits nn.MultiheadAttention.forward to a fused C++ kernel (_native_multi_head_attention) when its preconditions are met. That kernel has no ONNX symbolic at any opset:

torch.onnx.errors.UnsupportedOperatorError: Exporting the operator
'aten::_native_multi_head_attention' to ONNX opset version 17 is not supported.

Patch every MHA instance’s forward with a drop-in that uses only ops with stable ONNX symbolics:

def _onnx_friendly_mha_forward(self_, query, key, value,
                                key_padding_mask=None, need_weights=True,
                                attn_mask=None, average_attn_weights=True,
                                is_causal=False):
    if self_.batch_first:
        query, key, value = (t.transpose(0, 1) for t in (query, key, value))
    tgt_len, bsz, embed_dim = query.shape
    head_dim = embed_dim // self_.num_heads

    if self_._qkv_same_embed_dim and torch.equal(query, key) and torch.equal(key, value):
        q, k, v = F.linear(query, self_.in_proj_weight, self_.in_proj_bias).chunk(3, dim=-1)
    else:
        # cross-attention path: three separate projections
        w_q, w_k, w_v = self_.in_proj_weight.chunk(3)
        b_q, b_k, b_v = (self_.in_proj_bias.chunk(3)
                         if self_.in_proj_bias is not None else (None, None, None))
        q = F.linear(query, w_q, b_q)
        k = F.linear(key,   w_k, b_k)
        v = F.linear(value, w_v, b_v)

    q = q.contiguous().view(tgt_len, bsz * self_.num_heads, head_dim).transpose(0, 1)
    k = k.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)
    v = v.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)

    attn = F.softmax(torch.bmm(q * head_dim ** -0.5, k.transpose(1, 2)), dim=-1)
    out  = torch.bmm(attn, v).transpose(0, 1).contiguous().view(tgt_len, bsz, embed_dim)
    return self_.out_proj(out), None

for m in model.modules():
    if isinstance(m, nn.MultiheadAttention):
        m.forward = types.MethodType(_onnx_friendly_mha_forward, m)

Parity vs the fused kernel: 1 × 10⁻⁶ max diff. Safe.

The export call

Short answer: Legacy torch.onnx.export at opset 17, dynamo=False. dynamo_export dies on the patches anyway; legacy works.

from demucs.pretrained import get_model

bag = get_model("htdemucs_ft")
drums_model = bag.models[0].eval().cpu()
# apply all 4 patches above to drums_model

n = int(float(drums_model.segment) * int(bag.samplerate))   # 343980
dummy = torch.randn(1, 2, n, dtype=torch.float32)

torch.onnx.export(
    drums_model,
    dummy,
    "htdemucs_ft_drums.onnx",
    input_names=["mix"],
    output_names=["stems"],
    opset_version=17,
    dynamo=False,
    do_constant_folding=True,
)

316 MB per specialist. ~6.5 s export time on CPU. Passes onnx.checker.check_model. 24,765 nodes.

Repeat for bag.models[1] (bass), bag.models[2] (other), bag.models[3] (vocals). All four use the same architecture and patches.

Parity verification — the only acceptance test that matters

Short answer: Run the original PyTorch model and the ONNX model on the same fixed input, compute .abs().max(). Should be < 1e-3.

import numpy as np
import onnxruntime as ort

x = np.random.randn(1, 2, 343980).astype("float32")
sess = ort.InferenceSession("htdemucs_ft_drums.onnx",
                            providers=["CPUExecutionProvider"])
onnx_out = sess.run(["stems"], {"mix": x})[0]

torch_out = drums_model(torch.from_numpy(x)).detach().numpy()
print("max abs diff:", np.abs(onnx_out - torch_out).max())   # 1.63e-4

Per stem, against the original PyTorch htdemucs_ft at fp32:

All comfortably under the 1e-3 tolerance that fp32 reordering normally explains. SDR scores measured against MUSDB18-HQ are unchanged — if you want to verify yourself, query the 800-row leaderboard from pandas without re-running the benchmark.

Inference with zero PyTorch (pure numpy + onnxruntime)

Short answer: Load the four ONNX files, do overlap-add chunking, sum the per-model outputs.

import numpy as np
import onnxruntime as ort
import soundfile as sf

SOURCES = ["drums", "bass", "other", "vocals"]
CHUNK = 343980             # 7.8 s * 44100 Hz
HOP   = CHUNK // 4

sessions = {
    s: ort.InferenceSession(f"htdemucs_ft_{s}.onnx",
                            providers=["CPUExecutionProvider"])
    for s in SOURCES
}

def separate(mix, sr=44100):
    pad = CHUNK - (mix.shape[-1] % CHUNK)
    mix_p = np.pad(mix, ((0, 0), (0, pad)), mode="constant")
    out = {s: np.zeros_like(mix_p) for s in SOURCES}
    weight = np.zeros(mix_p.shape[-1])
    w = np.hanning(CHUNK).astype("float32")

    for start in range(0, mix_p.shape[-1] - CHUNK + 1, HOP):
        chunk = mix_p[:, start:start+CHUNK].astype("float32")[None]
        for s in SOURCES:
            y = sessions[s].run(["stems"], {"mix": chunk})[0][0]
            target_row = SOURCES.index(s)
            out[s][:, start:start+CHUNK] += y[target_row] * w
        weight[start:start+CHUNK] += w

    for s in SOURCES:
        out[s] = (out[s] / np.maximum(weight, 1e-8))[:, :mix.shape[-1]]
    return out

mix, sr = sf.read("song.wav", dtype="float32", always_2d=True)
stems = separate(mix.T, sr)
for s in SOURCES:
    sf.write(f"{s}.wav", stems[s].T, sr)

Zero PyTorch. Zero MLX. Runs anywhere onnxruntime runs — iOS via onnxruntime-objc, Android via onnxruntime-android, browsers via onnxruntime-web.

Performance numbers

Short answer: ONNX Runtime CPU EP is 1.31× faster than PyTorch CPU. A single-specialist ONNX is ~5.7× faster than the full bag.

Apple M4 Pro, 3-minute song:

The single-specialist trick works because the htdemucs_ft bag is one-hot:

# the bag's per-model weight matrix
weights = [[1, 0, 0, 0],   # drums  = sub-model 0's drums output
           [0, 1, 0, 0],   # bass   = sub-model 1's bass output
           [0, 0, 1, 0],   # other  = sub-model 2's other output
           [0, 0, 0, 1]]   # vocals = sub-model 3's vocals output

Sub-model 3’s vocals output is the bag’s vocals output, bit-exact. If you’re building a vocal remover, ship sub-model 3 alone (~316 MB ONNX, ~75 MB quantized) instead of the full ~1.26 GB bag at identical per-stem quality.

Wrapping Up

The five new ONNX repos — all MIT-licensed, all parity-verified:

• StemSplitio/htdemucs-ft-onnx — full 4-stem bag + numpy aggregator
• StemSplitio/htdemucs-ft-drums-onnx
• StemSplitio/htdemucs-ft-bass-onnx
• StemSplitio/htdemucs-ft-other-onnx
• StemSplitio/htdemucs-ft-vocals-onnx

If you’d rather skip the deployment plumbing entirely, the StemSplit hosted vocal remover runs the exact same htdemucs_ft weights with credits, queueing, and a dashboard — same model, just hosted. The full long-form writeup on the StemSplit blog has the iOS/Swift, Android/Kotlin, and onnxruntime-web code samples as well.

Open an issue on any of the repos if you find a stem where your parity diff exceeds 1e-3 — would love to hear about it.

This is a submission for the Hermes Agent Challenge

Hey everyone! 👋 Hima Kartikeya here.

If you’ve seen my recent posts, you know I just finished my Class 10 ICSE board exams and I’m currently getting ready to start my polytechnic diploma journey. My ultimate dream is a career in Cyber Security, but on the side, I’m a small-scale indie game developer who loves storytelling and world-building.

When I saw the Hermes Agent Challenge, my brain didn’t just think about standard business automation or data spreadsheets. I immediately wondered: How can we use autonomous AI Agents to revolutionize the way we learn cyber security through interactive gaming?

When most people think of AI, they think of chat interfaces waiting for a prompt. But AI Agents are a completely different beast—they can think ahead, adapt to changes, use external tools, and execute a multi-step plan entirely on their own. Here is my concept for how indie creators can use agent frameworks to build the ultimate Cyber Security RPG.

🎮 The Core Concept: An Autonomous Virtual Adversary

Imagine a text-based terminal game where you play as a junior system administrator defending a simulated corporate network. Instead of fighting a static, pre-scripted game boss with predictable patterns, your opponent is a live AI Adversary Agent powered by Hermes.

The setup is simple but dynamic. The agent is given a strict goal: “Find a vulnerability in the player’s network configuration and exfiltrate the secret data flag.”

The game loop unfolds in real-time:

1. The Agent Probes: The AI agent reads the current state of the game network (represented as environment variables or system logs).
2. The Agent Acts: It dynamically decides to execute a virtual “port scan” or try to exploit a weak variable handler.
3. The Player Reacts: The player sees the incoming connection logs and has to quickly write Python fixes, patch vulnerable loops, or close ports to stop the intrusion.

Because the agent can pivot and alter its strategy based on the specific defensive choices the player makes, no two playthroughs are ever identical!

🧠 Why Agent Reasoning Fits Perfectly with Game Logic

What makes a framework like Hermes brilliant for this kind of game design is its native capability for complex Reasoning, Planning, and Tool Execution (often called the ReAct framework).

Instead of a developer hardcoding millions of lines of complex “if/else” logic to simulate a smart hacker, the agent handles the decision-making loop naturally:

• Observation: The agent checks the game state (“The player left a loop configuration unprotected on Port 80”).
• Thought: It processes the logic (“An open port with unvalidated input means I can try to trigger a buffer overflow or a local Denial of Service”).
• Action: It calls a specific virtual terminal tool within the game environment to execute the exploit.

For a student developer like me, this completely changes the scope of what is possible. It democratizes game AI, letting indie creators focus entirely on crafting deep narratives, realistic environments, and great educational security lessons.

💡 Final Thoughts: The Ultimate Classroom

Stepping into my diploma studies soon, I know that reading static security textbooks can sometimes get a bit dry. But when you transform that textbook into a living, breathing digital opponent—an autonomous agent actively trying to outsmart your code—learning secure programming habits becomes an addictive, competitive experience.

Tools like Hermes prove that open agentic systems aren’t just for automating corporate tasks. They are powerful platforms for building next-generation educational tools that can help train the next wave of security defenders.

Over to the Community:
To the senior developers, game designers, and AI engineers out there: If you were integrating an autonomous AI agent into a video game today, would you design them to be a clever ally helping the player guide the narrative, or an unpredictable adversary trying to beat them? Let’s brainstorm in the comments! 🚀👇

Savings Plan amortized cost converts a front-loaded or recurring Savings Plan fee into a daily rate you can actually reason about. The default unblended view shows what AWS billed your account each day so a 1-year All Upfront Savings Plan appears as a single large charge on Day 1, then silence for 364 days. Accurate for cash flow. Operationally useless for tracking commitment ROI, allocating costs to teams, or detecting underutilization.

Here’s what amortized cost is technically, how it differs from unblended and blended, and critically how to use it to catch unused commitment before it compounds.

What Is Savings Plan Amortized Cost?

Amortized cost is a cost dataset in AWS Cost Explorer and the Cost and Usage Report (CUR) that spreads Savings Plan fees uniformly across each day of the commitment term. It’s an accrual accounting view of your cloud spend.

The formula AWS applies:

Daily Amortized Fee = (Total Plan Fee) ÷ (Total Days in Term)

For a 1-year No Upfront Compute Savings Plan at $10/hour ($87,600/year):

• Daily amortized fee: $87,600 ÷ 365 = $240/day regardless of whether EC2 usage consumed 100% or 60% of coverage that day

For a 1-year All Upfront plan at $80,000:

• Unblended view: $80,000 on Day 1, $0 for Days 2–365

• Amortized view: $219.18/day every day of the term

The effective cost per covered compute-hour in the amortized view is the true discounted rate, the number finance should use for chargebacks, and the number you should monitor to verify your Savings Plan is performing as expected.

The key operational difference:

An unblended view tells you what happened to your AWS bill. An amortized view tells you whether your Savings Plan is working.

If usage drops 40% in Month 6 on an All Upfront plan, the unblended view gives you no signal the $80,000 is already spent. In the amortized view, Month 6 shows unused commitment cost as a daily line item. That’s the waste signal.

If you want to understand how On-Demand, Reserved, and Spot pricing compares before committing, we covered the full breakdown here On-Demand vs Reserved vs Spot Instances: The Complete AWS Pricing Guide

How to View Amortized Cost in Cost Explorer

Prerequisites:

• Cost Explorer enabled (Billing → Cost Explorer → Enable)
• At least one active Savings Plan
• Permissions: ce:GetCostAndUsage, ce:DescribeSavingsPlans

Step 1: AWS Console → Billing and Cost Management → Cost Explorer

Step 2: Set a date range covering your Savings Plan’s active period. 30 days minimum for utilization analysis.

Step 3: In the right-hand panel, open Advanced Options. The cost type defaults to Unblended.

Step 4: Select Amortized costs. If you have upfront Savings Plans, the previously lumpy daily cost line will flatten into a consistent daily rate.

Step 5: Group by dimension to see coverage distribution:

• Group by Service → EC2 vs. Lambda vs. Fargate coverage
• Group by Linked Account → which accounts received commitment coverage
• Filter: Purchase Option = Savings Plans → isolate commitment cost from on-demand

Step 6: In the amortized view, AWS surfaces two Savings Plan line items:

• Savings Plans recurring fee: daily amortized portion of the plan fee
• Savings Plans upfront fee: if All/Partial Upfront, also shown as a daily amortized value

When usage fully covers the commitment, these appear as negative offsets against on-demand charges, netting to the discounted rate. When usage doesn’t cover the commitment, the unused portion appears as a positive cost with no offsetting savings. That’s your waste.

What Unused Commitment Actually Looks Like

Assume a Compute Savings Plan committing to $5/hour ($43,800/year, 1-year No Upfront).

Daily Usage vs. Commitment Outcome
100% Full $5/hour applies, zero unused commitment
70% $3.50/hour applied, $1.50/hour unused = $36/day wasted

50% $2.50/hour unused, $60/day = $1,800/month for nothing

None of this is visible as a daily signal in the unblended view. In the amortized view, unused commitment appears as a real-time daily cost line.

At scale: A 30% underutilized Compute Savings Plan on a $500,000/year commitment generates $150,000/year in unused commitment spend that produces zero AWS resources. At $6–12K/day in potential waste for larger environments, a single underutilization event undetected for 30 days is a $180K–$360K problem.

If you’re thinking through how to size and time your commitment purchases, we broke down the strategy here AWS Savings Plan Buying Strategy: Layering, Timing & Right-Sizing Commitment

Amortized Cost Across Consolidated Billing Accounts

In an AWS Organization, Savings Plans purchased in a management account can apply across all linked accounts. The amortized view is the only Cost Explorer dataset that properly attributes this coverage.

AWS applies the Savings Plan to usage across linked accounts (roughly by account ID, then by service). Each linked account’s amortized cost reflects the discounted rate for covered usage, regardless of which account owns the plan. Unused commitment is allocated back to the plan-owning account.

Why this matters for chargebacks: The unblended view shows the purchasing account bearing the full Savings Plan cost. The amortized view distributes that cost to accounts that actually consumed coverage. For any accurate internal cost allocation, you must use amortized cost unblended will systematically overcharge the management account and undercharge linked accounts.

Sample Athena query to surface unused commitment by day:

SELECT
line_item_usage_start_date AS usage_date,
savings_plan_savings_plan_a_r_n AS plan_arn,
SUM(savings_plan_unused_commitment) AS daily_unused_commitment,
SUM(savings_plan_used_commitment) AS daily_used_commitment,
ROUND(
SUM(savings_plan_unused_commitment) /
NULLIF(SUM(savings_plan_used_commitment + savings_plan_unused_commitment), 0) * 100, 2
) AS unused_pct
FROM your_cur_table
WHERE line_item_line_item_type = ‘SavingsPlanNegation’
OR line_item_line_item_type = ‘SavingsPlanCoveredUsage’
OR line_item_line_item_type = ‘SavingsPlanRecurringFee’
OR line_item_line_item_type = ‘SavingsPlanUpfrontFee’
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

Verify CUR field names against your specific CUR configuration field availability depends on CUR version and configuration.

The most common CUR mistake: summing lineItem/UnblendedCost and savingsPlan/SavingsPlanEffectiveCost in the same aggregation. That’s double-counting. Choose one methodology and apply it consistently.

What the Amortized View Can’t Tell You

Amortized cost is necessary for commitment analysis but not sufficient for commitment management.

Latency: Cost Explorer data has a 24–72 hour refresh latency. Savings Plans utilization can lag by up to 3 days. At $6–12K/day in potential waste, a 72-hour refresh cycle means a utilization problem can compound to $18K–$36K before it appears in your dashboard.

No forward-looking signal: The amortized view shows historical commitment performance. It can’t tell you whether your current usage trajectory will overshoot or undershoot your commitment for the rest of the month.

No automated action: Cost Explorer shows you the problem of unused commitment as a daily cost line. Fixing it (adjusting commitment size, redistributing coverage, or recovering unused commitment value) requires a separate workflow.

Closing the Gap Between Signal and Action

Most teams review Savings Plans utilization monthly or quarterly. AWS Cost Explorer’s recommendation engine refreshes every 72+ hours. By the time a utilization drop appears, gets reviewed in a weekly FinOps meeting, and reaches a decision, 2–4 weeks of unused commitment may have accumulated.

Usage.ai refreshes commitment data every 24 hours. On a $500K/year Savings Plan with 20% underutilization, you’re burning ~$274/day in unused commitment and miss it for 3 days due to stale tooling, that’s $822 gone before anyone sees the signal.

The other differentiator: most vendors in this space issue credits when commitment goes unused. Credits apply against future AWS invoices. Usage.ai returns cash actual money back, not a discount on next month’s bill. Unused commitment stops being a sunk cost and becomes a recoverable one.

Setup operates at the billing layer with only no infrastructure changes, no access to production resources. Commitments are sized to actual baseline usage rather than peak, which directly reduces the unused commitment visible in your amortized cost view.

For FinOps teams managing a consolidated AWS Organization, the amortized view of unused Savings Plan commitment is the first diagnostic signal. The question is how fast you act on it.

How does your team currently monitor Savings Plan utilization Cost Explorer, CUR queries, a third-party tool, or something else?

For a deeper technical breakdown and additional insights, read the full article here → Understanding Savings Plan Amortized Cost in AWS Cost Explorer

If you’ve ever heard “tailor your resume for every application” and immediately thought that sounds exhausting, you’re not alone. Most people skip tailoring entirely — or spend hours rewriting a document from scratch — because no one explains what targeted tailoring actually looks like.

Here’s the reality: for most applications, strong resume tailoring is a top-half edit, not a full rewrite. If your base resume is solid, you can tailor it to a specific job description in roughly five minutes. This guide walks through the method step by step.

The Core Insight: Recruiters Compare, They Don’t Read in a Vacuum

When a recruiter opens your resume, they’re not assessing it as a standalone document. They’re comparing it against the specific job posting they wrote. ATS systems work the same way at scale — they’re built to identify how well a resume matches a particular set of requirements.

A well-written generic resume can still underperform because it doesn’t reflect the vocabulary or priorities of the role. Tailoring fixes that without requiring a full rewrite.

The 5-Minute Method

Minute 1: Highlight the Repeated Keywords in the Job Description

Start with repetition. Pull up the job posting and mark everything that appears more than once:

• Job title variations
• Tools and technical skills
• Core responsibilities
• Outcome words (optimize, analyze, lead, scale, automate)
• Domain terms (fintech, B2B SaaS, healthcare, compliance)

Don’t try to match every word. Focus on the 8–12 signals that actually define the role. For a software engineer posting, that might be: TypeScript, React, REST APIs, performance optimization, cross-functional collaboration.

Minute 2: Pick the 3 Requirements You Must Match

Not everything in a job description carries equal weight. Your goal is identifying the three requirements that would make a recruiter say “yes, this person looks plausible.”

Usually those are:

1. The core function of the role
2. The main tools or stack
3. The business outcome or scope

For a product manager role, if the posting repeats customer research, roadmap prioritization, and stakeholder communication — those three drive your edits, even if the JD lists 15 other things.

Minute 3: Rewrite the Summary and Skills Section First

The top of your resume gets scanned first, which makes it the fastest win.

Before: “Software engineer with experience building web applications and backend systems.”

After: “Software engineer with experience building React and TypeScript applications, shipping REST API integrations, and improving performance for internal and customer-facing tools.”

The second version presents the same real experience in the language the hiring team is already using. Then tighten the skills section so your most relevant tools are visible without scrolling.

Minute 4: Rewrite Only the 4–6 Bullets That Carry the Most Weight

This is where most of the tailoring value lives. Target:

• Your most recent role
• Your most relevant project
• One bullet that shows results
• One bullet that shows ownership or cross-functional work

Before: “Worked on APIs and frontend features for internal systems.”

After: “Built React workflows and Node.js REST APIs for internal operations tools, reducing manual processing time by 28% and improving cross-team reporting reliability.”

The second version names the tools, provides a concrete outcome, and mirrors the way real job descriptions are written. That’s the pattern.

Minute 5: Remove Bullets That Dilute the Match

Tailoring isn’t only about adding keywords — it’s also about cutting noise.

Remove or shorten bullets that:

• Don’t support the target role
• Repeat the same kind of work
• Use generic language without outcomes
• Make your resume look unfocused

Most resumes actually improve when 10–20% of the content is removed. Less noise means the relevant material stands out more clearly.

The 5 Mistakes That Make Resume Tailoring Ineffective

1. Rewriting the whole resume from scratch. You don’t need a new document for every application. You need a focused edit.

2. Copy-pasting the job description. Mirroring language is good. Pasting the JD directly into your resume is obvious and unconvincing.

3. Ignoring the top third of the page. If your summary, title, and skills block still look generic, the whole resume will feel generic — even if the bullets are great.

4. Only changing the skills section. Keyword overlap helps with ATS. Bullets are what make the resume believable to a human recruiter.

5. Never checking the final version against the posting. Tailoring should end with a comparison, not a guess. Run a final ATS check before submitting.

A Quick Checklist Before You Submit

• 8–12 key terms highlighted from the job description
• 3 must-match requirements identified
• Summary updated to reflect role language
• Skills section reordered for relevance
• 4–6 key bullets rewritten
• Off-topic bullets removed or shortened
• Final ATS comparison done

This takes about 5 minutes once you’ve done it a few times. The first run usually takes 10–15 minutes, and it gets faster every time.

One Tool Worth Using

If you want to move faster on the ATS comparison step, ManyOffer Resume Match lets you paste your resume and the job description side by side and immediately see which requirements, keywords, and phrasing are still missing.

Read the full article here

Been using ManyOffer to sharpen my own answers — if you want AI mock interviews with real LP feedback, they have a deal running through July worth checking out: Claim 1 free month here