Correct typo

_posts/2025-01-06-encapsulating-rod-cutting.html

@@ -336,7 +336,7 @@ <h3 id="fe67c3b6121e4be780bc3d7f3b166a00">
         Okay, to be perfectly honest, there's one more change that might be in order, but this is where I ran out of steam.  One remaining precondition that I haven't yet discussed is that the input list must not contain 'too big' numbers. The problem is that the algorithm adds numbers together, and since 32-bit integers are bounded, you could run into overflow situations. Ask me how I know.
     </p>
     <p>
-        Changing the types to use 64-bit integers doesn't solve that problem (it only moves the boundary of where overflow happens), but consistently changing the API to work with <a href="https://learn.microsoft.com/dotnet/api/system.numerics.biginteger">BitInteger</a> values might. To be honest, I haven't tried.
+        Changing the types to use 64-bit integers doesn't solve that problem (it only moves the boundary of where overflow happens), but consistently changing the API to work with <a href="https://learn.microsoft.com/dotnet/api/system.numerics.biginteger">BigInteger</a> values might. To be honest, I haven't tried.
     </p>
     <h3 id="641bc16e730542a1a4a231886d208f24">
         Functional programming <a href="#641bc16e730542a1a4a231886d208f24">#</a>