Repository navigation
Conversation
… What I’ve Learned So Far"
…ing for Real Conversations."
* Add blog post on how the bitbeam SameGame solver works Explains beam search, the bitplane board representation with PEXT gravity, the expand-once/materialise-survivors restructure, deterministic parallel output, and the clearing refutations — aimed at both technical and non-technical readers. * Add demo GIF and post images, rewrite bitbeam post Add a recording of the bot playing SameGame in the browser with bitbeam choosing the moves, optimised from 9.2 MB to 3.5 MB with gifsicle, plus cover, thumbnail and share images derived from a board screenshot. Rewrite the prose to drop em dashes, bold runs, hook headings and the closing recap list. Cut the colour-merging aside and the fast-versus- reproducible tangent to keep the focus on the three main ideas. * Replace private repo links with code snippets The samegame-solver and samegame-bot repos are private, so the links went nowhere for readers. Drop both and show the approach directly instead: the bitplane Board struct, the PEXT gravity loop, the six-byte candidate record, and the tiebreak comparator that makes the parallel search deterministic. Also fix the Clickomania citation, which 404'd, and add the companion paper for the single-column grammar result. * Address PR review: recording pace, PEXT reference, sgbust numbers The GIF caption claimed the playback was slow enough to follow. It is a real-time recording at twenty clicks a second, which is too fast to see why a group was picked, so say that instead. Link PEXT to the instruction reference at its first mention rather than in the closing paragraph, which is where a reader first meets it. Link the genetic algorithm to the original public implementation, name the boards the results table was measured on, and replace the prose speedup claim with the measured per-routine numbers against sgbust. sgbust gets no row in the results table because it does not build here; say so under the table rather than leaving the omission unexplained. * Explain what beam search is, not just what it does The section jumped straight into the procedure without saying where the algorithm sits. Add a short paragraph placing it as a pruned best-first search: best-first ranks every partial solution and holds all of them, beam search caps the set so memory is chosen up front rather than grown, and the cost is that it is greedy with no optimality guarantee. Link the first mention to the Wikipedia article, and drop the trailing clause about discarding the best line, which the new paragraph now says. * Attach conditions to the performance numbers The intro claimed a 30x20 board solves in a couple of seconds. The README measures 3-10 s at three colours, and at five colours two of three boards found no clear at all after ~45 s, so the claim was the best case of the easy colour count stated as the general case. Give the three-colour figure and the 15x10 one instead. The 3,718 to 1,306 ms figure carried no board, and following the intro it read as if it described the 30x20 case. Name it: 15x15 at beam 10000. * Center the demo GIF, drop duplicate citation, fix sgbust contradiction The post called sgbust the reference point and then said it does not build, without explaining how both can be true. Say up front that its routines were transcribed into bitbeam's benchmark because the program itself cannot run here, so the later note reads as consistent. Checking that claim against the session logs from the solver repo, the build was never actually attempted; the conclusion came from reading its CMakeLists and its use of std::execution::par, which libc++ does not implement. State those blockers rather than an untested build outcome, and add the benchmark conditions (single thread, best of four rounds) that the run output records. Also center the GIF, keep only one of the two Clickomania citations, and reword the Ruby paragraph, which opened with a second "caveat" directly after the caveats sentence the sgbust table introduced. * Address review: fix contradictions, cite refutations, re-measure The opening no longer claims a cleared board is perfect play or that a move can only be judged by playing it out — both were refuted later in the post. Idea 2 drops the "fits in a register" overclaim (only one bitplane of one column does), adds occ() so the second snippet's names resolve, and covers column collapse and PEXT's x86-only portability. Idea 3 is renamed "do not record": every child is built and scored, only the survivors are stored, and the speedup is qualified as end-to-end. Corrections: Ruby's cost is interpreter dispatch and a missing popcount, not an allocation per shift; refutations do not stop the search hanging, since beam search always terminates; the chessboard rule now carries its size condition and its source (Takes and Kosters, Theorem 3), and the one-column grammar cites Biedl et al. The determinism section claims scaling rather than zero cost, since no non-deterministic build was raced against it. Numbers re-measured on this machine: a 30×20 three-colour board solves in two to four seconds at beam 5000, not three to ten, which is also the pause visible between boards in the recording. The GIF is 74 seconds for seven 30×20 boards, about fifty moves each at six to seven clicks a second, matching the bot's 0.1 s inter-click wait — the old "twenty clicks a second" did not reconcile. Machine, beam widths and the GA's configuration are now stated, along with the caveat that the GA is single-threaded Ruby. * Say memory usage, not memory, in the beam search paragraph * Rewrite the prose in plain language, drop the em dashes * Give Ruby a fair hearing in the solver comparison The bit-packing paragraph blamed Ruby for what is a gap in CRuby: no Integer#popcount and no way to emit a PEXT, neither of which the language forbids. The head-to-head table is re-measured on six 15x10 three-colour boards, wall clock, with two more configurations of the Ruby solver. YJIT takes the evaluation loop 2.7x faster and Ractors cut a population-64 run from 7.9 s to 3.3 s across eight cores, which buys score through a larger population: 2,031 -> 2,613 -> 2,852. bitbeam still scores 3,676 in 136 ms, so the remaining gap is the algorithm rather than the language, and the post now says that. The 12x rewrite figure and the Marshal profile are included to make the same point: the old Ruby solver was slow because of what it did per move, not because of what it was written in.
Comments were enabled site-wide but no provider was configured, so posts rendered no comment section at all. giscus backs threads with GitHub Discussions, which suits a readership that already has GitHub accounts. Repository and category IDs come from the GitHub GraphQL API. giscus cannot see the site theme, so the page has to tell it. The sync script watches body for class changes rather than listening for clicks on #change-skin: skin-switch.js binds its handler at jQuery ready, and an inline listener would register first and read the class before the toggle flipped it. It also waits for the iframe's first postMessage, since anything sent before that lands nowhere.
The recording of the bot clearing seven boards sits at roughly 85% depth, which is past where most readers stop. One clause in the intro gives a scanner somewhere to go without putting a summary box in front of the opening paragraphs.
The intro invites readers to see the puzzle rather than read about it, but the only interactive version lived at /public/samegame and the post never linked there for hands-on play. A "Try it yourself" section now embeds a small board right after the rules are stated. The embed reuses the standalone game verbatim: samegame.js is loaded as is and the board size is pinned through its own config proxy. samegame.js gains one seam for this, a gameOver(total) method holding what was inline in clickBall, so the default still shows the alert and the standalone page is unchanged while the embed overrides it with an on-board message and an imperative "Try again!" that restarts the game. samegame-embed.css is a scoped rebuild of samegame.css: every rule is confined to .samegame-embed so the standalone's global body styling cannot leak into the page, the blog's default table borders are reset on the board, balls shrink on narrow screens, and the scoreboard padding is trimmed to 4px so it matches the 12-column board width and the rounded corners meet without a seam.
Walks through the penny-rounding problem that shows up when a tax-inclusive bill is paid in installments, and the approach PennyWise takes: count in integer atoms, extract the whole bill's tax once, then read a floored running total whose per-payment differences telescope to the exact bill total. Splitting a bill between several payers is the same partition, so it reconciles for free. The mathematics is kept language-agnostic and shown as pseudo-code rather than linking the library, which is private. Adds an interactive "tax meter" as a Liquid include: enter a total, rate and installment count, then compare per-installment rounding (what a receipt line shows) against the running-floor method, with a live reconciliation table, a "plug the last installment" toggle, and a cumulative-error strip. Self-contained HTML/CSS/JS, integer maths via BigInt, theme-aware for the night-mode toggle, and responsive.
Pull upstream beautiful-jekyll updates. Resolved conflict in assets/css/beautifuljekyll.css by keeping the site's themed #social-share-section link colors (CSS variables for night mode) instead of upstream's removal of the hardcoded color. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mj4E3wsWuNAGEYxFXa3fNX
The "Floor, not round" section argues that the floored running tax total is a staircase approximating a straight line, and that this is Bresenham's line algorithm wearing a suit. This adds a widget that shows it directly, right after that claim. A 36-atom bill is laid out atom by atom along the x-axis; the tax owed rises as a straight line to (36, T) where T is the floored tax content for the chosen rate. One pixel is lit per atom on the tax level the floored staircase occupies there, coloured blue where the atom is net and orange where the line stepped up. Below each installment its own net + tax split is printed, the counts never differ by more than one and sum to exactly T. Two sliders: installments (1 to 12) and tax rate (1% to 50%). A toggle redraws the staircase with round instead of floor, so the rounded path visibly climbs above the true line while the floored one never does. Self-contained HTML/CSS/JS as a Liquid include, matching the existing tax-meter widget: theme-aware for the night-mode toggle, fixed-size SVG so axis labels do not scale with the graph, degenerate cases handled (T = 0 at low rates collapses to a single all-net row). Also wires up the post's cover, share and thumbnail images from a rendering of the widget: a darkened, letterboxed staircase for the hero and cropped versions for the share card and post-list thumbnail.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: ⛔ Files ignored due to path filters (75)
📒 Files selected for processing (67)
📝 WalkthroughWalkthroughThe repository was converted into a personal Jekyll blog with custom branding, dark mode, comments, new posts, interactive tax and game widgets, public browser applications, and a triangle-mesh editor. ChangesSite personalization and theme
Embedded interactive widgets
Public browser applications
Blog content
Estimated code review effort: 5 (Critical) | ~120 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 Biome (2.5.10)assets/css/beautifuljekyll.cssassets/css/skin-switch.cssassets/img/favicons/manifest.json
Warning Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit hops through pages bright, Comment |
|
Opened against the wrong repo by mistake (fork of beautiful-jekyll). Closing. Apologies for the noise. |
What
Adds a second interactive widget to the PennyWise post, in the "Floor, not round, and why that is the honest choice" section, right after the sentence that names Bresenham's line algorithm.
The widget makes that paragraph's claim visible: the floored running tax total is a staircase approximating a straight line, placed exactly the way a screen draws a slanted line on a pixel grid.
(36, T), whereT = floor(36·r / (100 + r)).net + taxsplit; the tax counts never differ by more than one and sum to exactlyT.roundinstead offloor— the rounded staircase visibly climbs above the true line, the floored one never does.Self-contained HTML/CSS/JS Liquid include, matching the existing tax-meter widget: theme-aware for the night-mode toggle, fixed-size SVG so axis labels don't scale with the graph, and degenerate cases handled (at 1–2% the tax floors to zero and the grid collapses to a single all-net row).
Post images
Wires up the previously commented-out
cover-img/thumbnail-img/share-imgfrom a rendering of the widget:staircase-cover-dark.pngstaircase-share.pngstaircase.pngTesting
Built locally and checked in the browser across the slider range, both themes, the round/floor toggle, and the degenerate low-rate case; verified the hero renders behind the post title and the thumbnail shows in the home list.
Summary by CodeRabbit
New Features
Updates
Removed