From bc9565609d004ad69636231de195a0197bebff27 Mon Sep 17 00:00:00 2001 From: Sadeep Madurange Date: Wed, 19 Aug 2026 05:58:52 +0800 Subject: Minor update. --- _log/2d-geometry-kernel.md | 25 +++++++++++++------------ _log/bumblebee.md | 5 ++--- _log/site-search.md | 8 ++++---- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/_log/2d-geometry-kernel.md b/_log/2d-geometry-kernel.md index e6c67e2..e3594f0 100644 --- a/_log/2d-geometry-kernel.md +++ b/_log/2d-geometry-kernel.md @@ -6,10 +6,10 @@ layout: post Written in 2026, backdated to 2022. -Real estate firm decided to rewrite the building design system from C# to Java. -Building geometries are small—mostly 2D. No frame budgets or low-latency -constraints. Numerical parity with Rhino was mandatory. Architects and -structural engineers supplied test cases and floating-point tolerances. +Firm decided to rewrite the building design system from C# to Java. Geometries +are small—mostly 2D. No frame budgets. Numerical parity with Rhino was +mandatory. Architects, structural engineers supplied test cases and +floating-point tolerances. Implemented polygon clipping with Sutherland–Hodgman. No drama. @@ -17,13 +17,14 @@ Fortune's algorithm was a missed opportunity. Implemented the beach line using a linear list instead of the balanced binary tree. Planned to return to this; never had the chance. -Z and H-shaped floor plan offsets produced self-intersections that even Rhino -mishandled. Could not get straight skeletons working under time pressure. Wrote -a custom solver that fixed invalid loops by backtracking instead. +Couldn't get straight skeletons working. Even Rhino mishandled +self-intersections Z and H-shaped floor plan offsets produced. Wrote a custom +solver that fixed invalid loops by backtracking. -Problem of finding the largest inscribed rectangle was surprisingly difficult. -No single algorithm covered both convex and concave shapes. Brute-force grid -search yielded 12% more buildable area—but not the true optimum. +Problem of finding the largest inscribed rectangle surprised me. No single +algorithm covered both convex and concave shapes. Brute-force grid search +yielded 12% more buildable area—but not the true optimum. + +BSP library proved numerically incompatible with Rhino. Replaced BSP trees with +vector-based primitives and JBLAS instead. All tests passed. -Java BSP library proved numerically incompatible with Rhino. Replaced BSP trees -with vector-based primitives and JBLAS instead. diff --git a/_log/bumblebee.md b/_log/bumblebee.md index 0a9ab49..c8dbd6f 100644 --- a/_log/bumblebee.md +++ b/_log/bumblebee.md @@ -19,9 +19,8 @@ sessions and synthesize browser automation scripts. Andy helped. JS hooks, WebView2 browser, Scintilla.NET editor emit events. Backend interprets them and emits Selenium code. -Two linear lists store events and code—no time for ASTs. Mid-session manual -edits desync lists, block optimizer. Workaround: only edit script after -recording. +Two linear lists store events and code—no ASTs. Mid-session manual edits desync +lists, block optimizer. Workaround: only edit script after recording. 2025-03: Shipped first iteration. Began work on key optimization: bypass the browser, grab data files directly. diff --git a/_log/site-search.md b/_log/site-search.md index 55e40be..78f9b76 100644 --- a/_log/site-search.md +++ b/_log/site-search.md @@ -93,11 +93,11 @@ Index size | 103557.18 KB | N/A ------------------------------------------------------------------------ -Search scales well—0.9ms at 100 files, 8.8ms at 5000. Indexing doesn’t: 4.5s -at 300 files is tolerable; 138s at 5000 is impractical. At six articles a year, -the indexer should remain viable for ~100 years. +Search scales well—0.9ms at 100 files, 8.8ms at 5000. Indexing doesn’t: 4.5s at +300 files is tolerable; 138s at 5000 is impractical. At five articles a year, +the indexer should remain viable for 60 years. -Next release: SA-IS O(n), Anno Domini 2126. +Next release: SA-IS O(n), Anno Domini 2086. Commit: