<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>jimmy-yang.dev</title>
      <link>https://jimmy-yang.dev</link>
      <description>Rust, mathematics, cryptography, zero-knowledge proofs</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://jimmy-yang.dev/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Sat, 25 Jul 2026 00:00:00 +0000</lastBuildDate>
      <item>
          <title>FPT-Sized Zero-Knowledge Proofs for Table Edit Distance</title>
          <pubDate>Sat, 25 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jimmy-yang.dev/posts/fpt-sized-zkp/</link>
          <guid>https://jimmy-yang.dev/posts/fpt-sized-zkp/</guid>
          <description xml:base="https://jimmy-yang.dev/posts/fpt-sized-zkp/">&lt;p&gt;The previous posts established a complete picture: table edit distance is
NP-hard, treewidth controls the boundary, polymorphisms explain why, and
coordinate descent is the practical workaround. This final post asks a
different question: &lt;strong&gt;can the hardness be used constructively?&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;Zero-knowledge proofs let a prover convince a verifier that a statement is
true without revealing &lt;em&gt;why&lt;&#x2F;em&gt;. “These two medical databases have edit
distance at most 50” — provable without revealing a single patient record.
“Two financial reports differ in fewer than 10 cells” — verifiable without
exposing the numbers.&lt;&#x2F;p&gt;
&lt;p&gt;The challenge: generic ZKP compilation of NP-hard problems produces
exponential-size proofs. The opportunity: &lt;strong&gt;bounded treewidth&lt;&#x2F;strong&gt; — the same
structural property that enables FPT algorithms — also bounds the proof
size. This post sketches how.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Coordinate Descent: Engineering Around NP-Hardness</title>
          <pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jimmy-yang.dev/posts/coordinate-descent/</link>
          <guid>https://jimmy-yang.dev/posts/coordinate-descent/</guid>
          <description xml:base="https://jimmy-yang.dev/posts/coordinate-descent/">&lt;p&gt;&lt;a href=&quot;&#x2F;posts&#x2F;tate-edit-distance&#x2F;&quot;&gt;Previous posts&lt;&#x2F;a&gt; established that table edit
distance is NP-hard, that treewidth controls the boundary, and that the
algebraic root cause is the absence of compositional structure. Theory is
clean; reality is messy. Users of
&lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https:&#x2F;&#x2F;github.com&#x2F;j-yang&#x2F;tate&quot;&gt;&lt;code&gt;tate&lt;&#x2F;code&gt;&lt;&#x2F;a&gt; need to diff tables &lt;em&gt;today&lt;&#x2F;em&gt;, and
they need the result in milliseconds, not in the exponential time that
exact computation would require.&lt;&#x2F;p&gt;
&lt;p&gt;This post covers tate’s practical answer: &lt;strong&gt;coordinate descent&lt;&#x2F;strong&gt; — an
alternating optimization scheme that exploits the one structural property
the NP-hardness result leaves intact: for any &lt;em&gt;fixed&lt;&#x2F;em&gt; column alignment, the
row alignment problem is polynomial (it’s 1D LCS).&lt;&#x2F;p&gt;
&lt;p&gt;We prove convergence, characterize the optimality gap, and show how the
algorithm maps to tate’s Rust implementation.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Tensor Rank and Higher Dimensions</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jimmy-yang.dev/posts/tensor-rank-and-higher-dimensions/</link>
          <guid>https://jimmy-yang.dev/posts/tensor-rank-and-higher-dimensions/</guid>
          <description xml:base="https://jimmy-yang.dev/posts/tensor-rank-and-higher-dimensions/">&lt;p&gt;&lt;a href=&quot;&#x2F;posts&#x2F;tate-edit-distance&#x2F;&quot;&gt;Post 1&lt;&#x2F;a&gt; established that table edit distance
is NP-hard and that treewidth controls the boundary. &lt;a href=&quot;&#x2F;posts&#x2F;polymorphisms-and-dp&#x2F;&quot;&gt;Post
2&lt;&#x2F;a&gt; traced the boundary to its algebraic
root: 1D solutions compose (lattice structure), 2D solutions don’t.&lt;&#x2F;p&gt;
&lt;p&gt;Now we ask: what about three dimensions? Four? $d$?&lt;&#x2F;p&gt;
&lt;p&gt;The answer involves a beautiful parallel. The complexity boundary
$d = 1$ vs $d \geq 2$ in edit distance maps exactly onto the boundary
between &lt;strong&gt;matrix rank&lt;&#x2F;strong&gt; (polynomial) and &lt;strong&gt;tensor rank&lt;&#x2F;strong&gt; (NP-hard). This
is not a surface analogy — the coupling structure that makes 2D edit
distance hard is the same structure that makes tensor decomposition hard.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Polymorphisms: Why Dynamic Programming Works</title>
          <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jimmy-yang.dev/posts/polymorphisms-and-dp/</link>
          <guid>https://jimmy-yang.dev/posts/polymorphisms-and-dp/</guid>
          <description xml:base="https://jimmy-yang.dev/posts/polymorphisms-and-dp/">&lt;p&gt;In &lt;a href=&quot;&#x2F;posts&#x2F;tate-edit-distance&#x2F;&quot;&gt;the first post&lt;&#x2F;a&gt;, we established that table
edit distance is NP-hard for any positive cost model, and that treewidth
controls the boundary: treewidth 1 (sequences) is polynomial, unbounded
treewidth (tables) is NP-hard, and bounded treewidth (few columns) is FPT.&lt;&#x2F;p&gt;
&lt;p&gt;But treewidth only tells us &lt;em&gt;when&lt;&#x2F;em&gt; the problem is tractable. It doesn’t
explain &lt;em&gt;why&lt;&#x2F;em&gt;. Why does the $O(nm)$ DP fill its table correctly for
sequences, but no analogous DP exists for tables? What is the structural
property that makes one case solvable and the other not?&lt;&#x2F;p&gt;
&lt;p&gt;The answer comes from universal algebra: &lt;strong&gt;polymorphisms&lt;&#x2F;strong&gt; — operations that
combine solutions into new solutions. When polymorphisms exist, the solution
space has compositional structure, and dynamic programming can exploit it.
When they don’t, no amount of clever algorithm design can compensate.&lt;&#x2F;p&gt;
&lt;p&gt;This is the same principle that underlies the CSP dichotomy theorem
(Bulatov 2017, Zhuk 2017), one of the deepest results in theoretical
computer science.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>On Edit Distance and Treewidth</title>
          <pubDate>Sat, 27 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jimmy-yang.dev/posts/tate-edit-distance/</link>
          <guid>https://jimmy-yang.dev/posts/tate-edit-distance/</guid>
          <description xml:base="https://jimmy-yang.dev/posts/tate-edit-distance/">&lt;p&gt;Edit distance for strings is a solved problem: $O(nm)$ dynamic programming,
textbook material. Edit distance for tables is NP-hard. The jump from
polynomial to intractable happens the moment you go from one dimension to two.&lt;&#x2F;p&gt;
&lt;p&gt;Why? The answer is a single number: &lt;strong&gt;treewidth&lt;&#x2F;strong&gt;. The constraint graph
underlying a 1D edit distance computation is a path (treewidth 1). The
constraint graph for a 2D table is a grid (treewidth $\min(\text{rows},
\text{cols})$). Every complexity result in this post — polynomial for
sequences, NP-hard for tables, fixed-parameter tractable when columns are
bounded — falls out of this one graph invariant.&lt;&#x2F;p&gt;
&lt;p&gt;This post accompanies &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https:&#x2F;&#x2F;github.com&#x2F;j-yang&#x2F;tate&quot;&gt;&lt;code&gt;tate&lt;&#x2F;code&gt;&lt;&#x2F;a&gt;, a
self-contained structured diff library in Rust. I’ll formalize table edit
distance, prove it’s a metric, prove it’s NP-hard for &lt;em&gt;any&lt;&#x2F;em&gt; positive cost
model (not just a specific one), and identify the treewidth boundary that
separates tractable from intractable.&lt;&#x2F;p&gt;</description>
      </item>
    </channel>
</rss>
