DEV Community: Lucian (LKB)

The North Star isn't the brightest star. It's not even in the top 40.

Lucian (LKB) — Fri, 11 Sep 2026 06:28:54 +0000

Syndicated from the original on lkforge.com. The ranking below is printed by one short, dependency-free script.

The North Star is the most famous star in the sky, and almost everyone assumes fame means brightness. It doesn't. Rank the stars by how bright they actually appear and Polaris isn't close to the top - it isn't even in the top forty.

The correction

Polaris ranks about 48th in apparent brightness.
The real brightest star, Sirius (magnitude -1.46), outshines Polaris (+1.98) by roughly 24 to 1.
Polaris shines at only 4.2% of Sirius, beaten by two dozen household-name stars before you even reach the fainter ones.

The actual brightest stars (as a share of Sirius)

#	Star	Brightness vs Sirius
1	Sirius	100%
2	Canopus	52%
3	Alpha Centauri	33%
4	Arcturus	27%
5	Vega	25%
6	Capella	24%
7	Rigel	23%
8	Procyon	19%
9	Betelgeuse	18%
...	...(35+ more)	...
~48	Polaris	4.2%

Why the numbers run backwards

The scale is the confusing part. Apparent magnitude measures brightness with smaller = brighter - a leftover from the ancient Greeks, who called the brightest stars "first magnitude" and the faintest "sixth." It's also logarithmic: every 5 steps of magnitude is a factor of exactly 100 in brightness.

So Sirius at -1.46 is genuinely brilliant, Polaris at +1.98 is middling, and a magnitude-6 star is at the edge of naked-eye visibility. To turn magnitudes into a linear "how many times brighter," you use:

brightness ratio = 10 ^ (-0.4 * delta-magnitude)

For Sirius vs Polaris that's a gap of ~3.44 magnitudes, or about 24x.

So why is Polaris famous?

Position, not brightness. Polaris sits within about 0.7 degrees of the north celestial pole - the point Earth's axis points at - so as the planet turns, every other star wheels in a circle while Polaris barely moves. It marks true north and holds still, which for two thousand years made it the single most useful star for navigation in the Northern Hemisphere.

It won't hold the job forever: Earth's axis slowly wobbles (precession), so the pole star changes over millennia - the bright star Vega sat near the pole around 12,000 BC and will again near 13,700 AD. Polaris is simply the star on duty now.

Reproduce it

Every figure comes from one short script: standard published apparent magnitudes (Hipparcos / Yale Bright Star Catalogue), ranked, then converted to linear brightness. Several bright stars are slightly variable, so ranks near a tie can shift a place; Polaris's ~48th is the widely cited figure.

Full write-up with the ranked chart is on the original: Is the North Star the Brightest? You can find Polaris and everything wheeling around it with the Sky Explorer.

The UN voted to drop the Mercator map. Here's exactly how wrong it was, measured.

Lucian (LKB) — Thu, 10 Sep 2026 21:24:50 +0000

Syndicated from the original on lkforge.com. The country data is the same set behind my World Atlas, and the script that prints every number below is public and dependency-free.

On September 4, 2026 the UN General Assembly backed a push to retire the Mercator projection - the world map most of us grew up with - in favor of equal-area maps. The complaint is old but correct: Mercator badly misrepresents size. I wanted the actual numbers, so I took the real land areas behind my World Atlas and measured it.

The headline: Greenland is not the size of Africa

On a Mercator map they look about equal. They are not close.

Africa is 14.0x larger than Greenland (30.3M km2 across 50 countries vs 2.17M km2).
Africa is 1.8x larger than Russia (17.1M km2), the biggest country on Earth.
Greenland is only the 12th-largest landmass on the list. Algeria alone (2.38M km2) is bigger than Greenland.

The real top of the ranking (millions of km2)

#	Country	Area
1	Russia	17.1
2	Canada	10.0
3	China	9.7
4	United States	9.4
5	Brazil	8.5
...	...	...
10	Algeria	2.4
11	DR Congo	2.3
12	Greenland	2.2

Why the map lies, in one formula

Mercator keeps compass directions straight, and the price is size. It stretches the map by a factor that grows toward the poles, on both axes - so area is scaled by that factor squared:

Mercator area inflation = sec^2(latitude)

Evaluate it at each country's centroid latitude and the whole illusion falls out:

Country	Centroid lat	Area shown on Mercator
Greenland	72 N	x10.5
Russia	60 N	x4.0
Canada	60 N	x4.0
United States	38 N	x1.6
DR Congo	0	x1.0
Brazil	10 S	x1.0

Greenland sits near 72 N, where Mercator inflates area more than tenfold - which is exactly how a 2-million-km2 island ends up looking like a 30-million-km2 continent. Countries on the equator are drawn true to size.

Reproduce it

Every figure here is printed by one short script that fetches the same country dataset (area + centroid latitude) my World Atlas ships and does the arithmetic - no dependencies. The centroid-latitude distortion is a per-country approximation, since a country spans latitudes, but it captures the effect.

The full write-up, with the ranked chart and the distortion table, is on the original: The True Size of Countries. You can watch the distortion appear and vanish by switching between the flat map and the globe in the atlas itself.

How Much Quality Do You Lose Compressing an Image? We Measured It on 24 Photos

Lucian (LKB) — Thu, 10 Sep 2026 07:01:24 +0000

"Compress without losing quality" is a promise lossy formats can't fully keep — every step of compression trades some fidelity for bytes. The useful question isn't whether you lose quality but how much, for how many bytes saved. So we measured the trade directly.

The method

Across the 24-image Kodak reference suite — the standard set for this kind of test — we saved every photo as JPEG and WebP at qualities 20 through 95, and scored each output on SSIM (structural similarity to the original, 0 to 1) rather than eyeballing it. Every figure below is the mean over all 24 images, so it's not one lucky photo.

Diminishing returns are brutal

The size-vs-quality curve bends hard: the first kilobytes buy almost all of the quality, and after that it flattens into a long tail where you pay a lot for very little.

The clearest example: pushing JPEG from quality 85 to 95 nearly doubles the file — from about 14% to 26% of the original — for an SSIM gain of just 0.025 (0.95 → 0.98). That is double the bytes for a difference most people can't see on most images. The habit of exporting at 95 or 100 "to be safe" is, for photographs, mostly wasted space.

Format beats quality-cranking

Changing the codec does more than turning the quality dial:

WebP is about 30% smaller than JPEG at the same SSIM — 29.6% smaller at SSIM 0.95, 31.9% at 0.97. Same perceived fidelity, a third less weight.
Staying fully lossless costs roughly 7× a quality-85 JPEG. "Keep it lossless to be safe" usually means paying seven times over for bytes no one will perceive.

The practical takeaway

For photographs, the sweet spot is quality 80–85, ideally in WebP. But the honest answer is that the right setting is image-dependent — a flat sky compresses beautifully, fine texture does not — so a live preview beats any single recommended number. Pick the point on the curve where the preview stops changing, not a fixed "95".

Reproduce it

The study is a straightforward encode-and-score sweep over the Kodak set, driven by a short script — point it at your own images and you'll get the same shape of curve. And if you just need to compress something, the image compressor and the rest of the image tools run entirely in your browser with a live preview — nothing uploaded.

Originally published on LK Forge.

Dollar-Cost Averaging vs Lump Sum: What 75 Years of S&P 500 Data Shows

Lucian (LKB) — Wed, 09 Sep 2026 06:02:28 +0000

You have a sum of money and you want it in the market. Do you invest it all at once, or feed it in gradually -- dollar-cost averaging -- so you don't buy right before a crash?

It's one of investing's oldest arguments, and it's answerable with data. So I ran it against every starting month of the S&P 500 from 1950 to 2025: deploy the whole amount now, or spread it evenly over the next few months, then compare which ended up ahead.

The headline result

Investing a lump sum beat spreading it over a year 76% of the time (S&P 500 total return, 1950-2025). And the longer you dragged the money in, the more often the lump won:

How long the money was spread in	Lump sum won	DCA won
6 months	72.4%	27.6%
1 year	76.2%	23.8%
2 years	82.7%	17.3%
3 years	86.3%	13.7%

The reason is mundane: the market goes up more often than it goes down, so money sitting on the sidelines waiting to be invested is money missing the average day's gain. On a concrete $10,000 deployed over a year, the lump sum finished about $607 ahead on average.

But averages hide the interesting part

Dollar-cost averaging lost the typical year. But when it won, it won for one reason: the market fell right after you started. Sort every one-year period by how much DCA beat the lump sum, and the top of the list isn't scattered across history -- it bunches up in one place.

The single best month to have been averaging in slowly rather than all at once was August 2008, on the eve of the financial crisis. DCA finished about 30 points ahead there, because each later purchase bought in cheaper as the market collapsed. The runners-up are the other months of 2007 and 2008.

So the honest reading: dollar-cost averaging is not a way to earn more, it's a way to be wrong by less when your timing is unlucky. You're trading a bit of expected return -- that ~$607 on $10,000 -- for protection against the one scenario everyone fears, putting it all in at the top. Whether that trade is worth it is about temperament, not math.

How it was measured

Like-for-like: both strategies invest the same total. The lump goes in at month zero; the DCA version splits it into equal monthly buys and both are compared at the end of the window, when both are fully invested. I used S&P 500 total return (dividends reinvested), and assumed the not-yet-invested DCA cash earns nothing (the conservative, common assumption). Every ending value is a real historical outcome, run for every start month 1950-2025, then tallied.

One scope note: this is the classic "deploy a windfall now vs later" question, not regular saving from a paycheck. If you invest each month as you earn it, you're already dollar-cost averaging by necessity -- there's no lump sum to compare against.

Check it yourself

The whole study is built on a monthly S&P 500 total-return index, and you can spot-check any single period in the two free, browser-based calculators it links to:

Full write-up with the interactive chart: Dollar-Cost Averaging vs Lump Sum
Dollar-Cost Averaging Calculator -- backtest investing a fixed amount every month
S&P 500 Return Calculator -- what a lump sum would have grown to

Past performance doesn't predict the future; this is history, not advice.

Why a Tuner and Your Ear Disagree: The 13.7-Cent Compromise

Lucian (LKB) — Tue, 08 Sep 2026 07:27:46 +0000

Tune a guitar perfectly to a digital tuner, play a full open major chord, and something is still faintly off — a slow shimmer in the sound. The tuner isn't wrong, and neither is your ear. They're using two different definitions of "in tune," and the distance between them is a fixed, computable number.

Two definitions of "in tune"

A digital tuner uses equal temperament: the octave is divided into twelve exactly equal steps of 100 cents each (a cent is 1/100 of a semitone). That perfect evenness is what lets one instrument play in all keys without retuning. Your ear, on the other hand, hears an interval as pure when its two frequencies form a simple whole-number ratio — a perfect fifth is 3:2, a major third is 5:4 — because then the waveforms lock and stop beating. The problem: those pure ratios don't land on the equal 100-cent grid.

How far apart they are

Computing the deviation for every interval (equal-tempered cents minus the pure ratio in cents):

Interval	Pure ratio	Equal temp.	Pure (cents)	Off by
Minor 2nd	16/15	100	111.73	−11.73
Major 2nd	9/8	200	203.91	−3.91
Minor 3rd	6/5	300	315.64	−15.64
Major 3rd	5/4	400	386.31	+13.69
Perfect 4th	4/3	500	498.04	+1.96
Tritone	45/32	600	590.22	+9.78
Perfect 5th	3/2	700	701.96	−1.96
Minor 6th	8/5	800	813.69	−13.69
Major 6th	5/3	900	884.36	+15.64
Minor 7th	9/5	1000	1017.60	−17.60
Major 7th	15/8	1100	1088.27	+11.73

The major third is 13.7 cents sharp, the major sixth 15.6 sharp, and the minor seventh nearly 18 out. But the perfect fifth is only 2 cents flat, and the fourth 2 cents sharp. Since a trained ear notices about 5 cents, the fifths and fourths pass as clean while the thirds and sixths carry the audible "tempered" beating. That's exactly the shimmer in the held major chord — the third is doing it.

Why it has to be this way

A piano can't be perfectly in tune and perfectly playable in every key at once — the two goals are mathematically incompatible. Equal temperament is the elegant surrender: spread the error evenly so no key is worse than any other. Instruments with no frets or keys — a string quartet, a barbershop quartet — can slide each note onto the pure ratio and get beat-free thirds. That pure sound is what your ear is quietly asking a fretted, tempered instrument for, and not quite getting.

What your tuner targets

A tuner takes each string's equal-tempered frequency and shows how many cents you're above or below it. All from f = 440 × 2^((m − 69) / 12):

Guitar: E2 82.41, A2 110.00, D3 146.83, G3 196.00, B3 246.94, E4 329.63 Hz
Bass: E1 41.20, A1 55.00, D2 73.42, G2 98.00 Hz
Violin: G3 196.00, D4 293.66, A4 440.00, E5 659.26 Hz
Ukulele: G4 392.00, C4 261.63, E4 329.63, A4 440.00 Hz

Reproduce it

const cents = (ratio) => 1200 * Math.log2(ratio)
const midiToFreq = (m) => 440 * 2 ** ((m - 69) / 12)
// major third: 100*4 - cents(5/4) = 400 - 386.31 = +13.69 cents

Full write-up, chart and the free browser tuners, tone generator and circle of fifths to hear it: Why a Tuner and Your Ear Disagree.

Originally published on LK Forge.

What the Average Big Five Result Actually Looks Like (n = 19,718)

Lucian (LKB) — Mon, 07 Sep 2026 04:21:38 +0000

Personality tests love to hand you a tidy "type". So we took 19,718 real Big Five responses — the IPIP-50 instrument, from the Open-Source Psychometrics Project — scored them into the five OCEAN traits, and looked at what the distribution actually says.

Nobody is average on everything

The first result is the bluntest one: 0 of 19,718 people scored in the top band on all five traits at once. Not a single person. "Average across the board" is a statistical fiction — real people are high on some traits, low on others, and middling on the rest. In fact 46% land in the middle band on three or more traits, which is why the confident one-word "type" a quiz gives you throws away most of the picture.

The traits barely relate to each other

The Big Five is designed so the five traits are close to independent, and the data agrees. The strongest correlation between any two traits is r = 0.33 (Extraversion and Agreeableness); across all ten pairs the average is |r| = 0.17. That's weak. Knowing someone is extraverted tells you almost nothing about whether they're conscientious or open. The common intuition — "she's outgoing, so she's probably organized too" — simply isn't in the numbers.

Which traits skew, and which spread

Not every trait is shaped the same. Openness and Agreeableness skew high (most people rate themselves above the midpoint), while Extraversion and Neuroticism have the widest spread — people are all over the range. So an "average" score on Openness is genuinely common, but an "average" score on Extraversion is almost a coin flip between reserved and outgoing.

The honest caveat

This is a self-selected online sample — people who chose to take a personality test. That biases the absolute means (the where of each peak), so don't read the exact averages as the human baseline. What it doesn't undermine are the shapes and the correlations: the near-independence of the traits and the near-total absence of "top on everything" people are robust to who showed up.

Try it / reproduce it

The free Big Five test uses the same IPIP-50 instrument, runs entirely in your browser, and asks for no signup. The full distribution study — every number above, plus the correlation matrix and per-trait histograms — is reproducible from a public script.

Originally published on LK Forge.

We Ran Our Own Blog Through Our Word Counter: 22.1 Words a Sentence

Lucian (LKB) — Sun, 06 Sep 2026 05:52:18 +0000

A word counter's least useful output is the word count. The number that shows up biggest is the one that matters least — the value is in the analysis underneath it: how long your sentences run, which words you lean on, how readable the whole thing actually is. So instead of describing what the tool measures, we pointed it at ourselves and reported what it found — including where it found a problem.

The corpus

We ran all 22 posts on this blog — 24,003 words across 1,084 sentences — through our own word counter. One writer, one blog, no cherry-picking: whatever the tool flagged, we kept.

We write long sentences

Average sentence length across the whole blog: 22.1 words. The common readability guideline is 15–20, so we run consistently over. And the average hides the tail — our worst post averaged 39.7 words a sentence, which reads as a wall of text no matter how carefully it's punctuated.

Long sentences aren't a sin; some ideas need the room. But drift is invisible without the number. You don't feel yourself creeping from 18 to 22 to 26 words a sentence over a year of writing — you just notice, eventually, that everything reads a little heavy. The counter makes the drift visible while you can still fix it.

Our crutch word wasn't on any list

The single most-overused word in the whole blog was "every" — 93 uses. It's not on a single "words to cut" list, because those lists are generic and crutch words are personal. Meanwhile the words those articles always name — very, really, just — barely appeared in our writing at all.

That's the whole argument for measuring your own text rather than running a canned checklist over it. A generic filler-word list can't know that you, specifically, reach for "every" when you mean "many." Counting your actual words can, and does.

The takeaway

Point the tool at your own writing first. The word count is trivia; the sentence-length distribution and your personal crutch words are the product. Fix the top one or two habits and every later post inherits the improvement — which is a far better return than obsessing over a target word count.

The word counter runs entirely in your browser — sentence and paragraph stats, reading time, keyword frequency, readability — with nothing uploaded. Run your last post through it and see what it says about you.

Originally published on LK Forge.

How Much Grass Seed Do You Actually Need? It Swings 5 by Grass Type

Lucian (LKB) — Sat, 05 Sep 2026 05:40:39 +0000

"How much grass seed for my lawn?" sounds like it should have one answer. It doesn't — and the surprise is that it depends more on the grass than the lawn. Using the seeding rates a grass-seed calculator ships (typical U.S. cooperative-extension figures), the amount you need swings 5.3× from one species to the next.

The seeding rate runs from 1.5 to 8

Seeding rate is measured in pounds per 1,000 square feet, and it's a property of the grass, not the yard:

Grass (new lawn)	lb per 1,000 sq ft
Perennial ryegrass	8
Tall fescue	7
Generic / mixed	5
Kentucky bluegrass	2.5
Bermuda	1.5

That's a 5.3× gap between perennial ryegrass and Bermuda, with the others across the middle.

What it means for a real lawn

Multiply the rate by your area in thousands of square feet and the gap becomes concrete. On the same 5,000 sq ft lawn:

Perennial ryegrass → 40 lb
Tall fescue → 35 lb
Kentucky bluegrass → 12.5 lb
Bermuda → 7.5 lb

Same yard, same job, five times the seed. Buy for the wrong grass and you either waste half a bag or sow too thin to fill in.

One bag, wildly different coverage

Flip it around and it's sharper still. A single 20 lb bag covers about 13,333 sq ft of Bermuda — but only 2,500 sq ft of perennial ryegrass, a 5.3× difference from the identical bag weight. Which is why "one bag does an average lawn" is useless advice: the bag doesn't know what grass is in it.

Why: seed size, not area

The reason is seed size. A good lawn is set by seeds per square foot, not pounds — and Bermuda seed is so small that a pound holds a vast number of them, while ryegrass seed is many times heavier, so a pound holds far fewer. Same target density, very different weight. That single fact is the whole 5.3× spread. (And overseeding an existing lawn uses about half the new-lawn rate, since you're thickening turf rather than covering bare soil.)

Reproduce it

Every figure is the rate table times one line of arithmetic:

const RATE = { 'perennial-rye': 8, 'tall-fescue': 7, 'generic': 5,
               'kentucky-bluegrass': 2.5, 'bermuda': 1.5 }   // lb / 1,000 sq ft
const pounds = (rate, areaSqFt) => rate * (areaSqFt / 1000)
// pounds(8, 5000) = 40 lb rye  ·  pounds(1.5, 5000) = 7.5 lb Bermuda

The rates are mid-range extension figures — a starting point; always follow your seed bag's label. The grass-seed calculator does this for your area and grass (with a rate override), in the browser.

Originally published on LK Forge.

Does That "Free Online PDF" Tool Upload Your File? How to Tell.

Lucian (LKB) — Fri, 04 Sep 2026 09:24:56 +0000

Most free online PDF tools work by uploading your document to a server, processing it there, and sending it back. For a lot of files that's fine. For a signed contract, a payslip, a medical form, or a scanned ID, it's the entire privacy problem: your document now lives on someone else's machine, subject to their logging, retention, and breach exposure.

It doesn't have to work that way. A modern browser can split, merge, compress, sign, and even OCR a PDF without the file ever leaving your device — using libraries like pdf-lib, pdf.js, jsPDF and SheetJS that run entirely in JavaScript.

How to tell an uploader from a client-side tool

You don't have to trust a marketing claim. Two checks settle it:

Watch the network. Open your browser's DevTools → Network tab, then run the tool on a file. If you see your file leave in a POST/PUT request, it uploaded. A client-side tool shows no upload of the document itself.
Pull the plug. Load the page, then turn off Wi-Fi and try the tool again. A client-side tool keeps working offline. An uploader breaks the moment the network is gone.

The honest tools pass both tests. If a site can't work offline, your file is going somewhere.

The trade-offs, stated honestly

Client-side processing isn't a free lunch, and any tool that pretends it is should make you suspicious:

Memory. Very large PDFs are held in browser memory, so there's a ceiling a server wouldn't have.
Speed. OCR in WebAssembly is slower than a server GPU. It's private, not fast.
Fidelity. Converting PDF → Word transfers the text, not the layout — the same is true of every converter, but a client-side one can't hide it behind a server.
Compression limits. A PDF shrinks by downsampling embedded images or rasterizing pages; a small or text-only PDF may not shrink at all, and rasterizing removes selectable text.

We built 24 client-side PDF tools on exactly this principle and wrote down where each limit is, rather than papering over them. If you're evaluating any online PDF tool — ours or anyone's — the network check and the offline check are the two minutes of due diligence worth doing before you upload something you'd rather not.

Originally published on LK Forge.

The Online JSON Formatter Guide: Formatter vs Validator, Privacy, and Four Time-Wasters

Lucian (LKB) — Fri, 04 Sep 2026 06:46:39 +0000

A single missing comma in minified JSON can cost you an hour. JSON is trivial to read and miserable to hand-edit — one misplaced bracket and the whole thing is invalid, with no compiler to point at the line. A formatter fixes that in a second, but "paste JSON into the first result in search" quietly causes more problems than it solves. Here's how to use one well.

Formatter vs validator: don't confuse the two

They sound interchangeable and aren't. A formatter pretty-prints — it takes valid (or nearly valid) JSON and lays it out with consistent indentation so you can read it. A validator tells you whether it's valid and, crucially, where it breaks — line and character of the offending token. When JSON won't parse, you want the validator's error location first; formatting broken JSON just rearranges the problem. Reach for the validator to find the fault, the formatter to make the fixed result readable.

Privacy is the one criterion you can't skip

JSON payloads carry the sensitive stuff: auth tokens, personal data, internal API shapes. Many online tools upload whatever you paste to a server to process it — which is exactly what you don't want for a payload with credentials in it. You don't have to guess:

Watch the Network panel. Open DevTools → Network and run the tool. If your input leaves in a request, it uploaded.
Pull the plug. A genuinely client-side tool keeps working with the network off. If it breaks offline, your data is going somewhere.

Confirm a tool processes data locally before you paste anything real into it.

Four mistakes that quietly waste hours

Pasting broken JSON into code without validating first. It resurfaces as a runtime error you then trace backwards. Validate before it ever reaches your codebase.
Pasting sensitive payloads into an unverified tool. Under time pressure it's tempting to grab the first search result. Confirm it's client-side before anything with credentials or personal data goes in.
Leaving pretty-printed JSON in production. Human-readable indentation is dead weight over the wire. Minify for deployment; keep the formatted version for your repo and reviews.
Mismatched indentation across a team. One person on tabs, another on four spaces, and a three-line change becomes a 400-line diff. Agree on one style — two spaces is the most common — and let the formatter enforce it.

When JSON isn't the final form

Once it's clean, the converters pick up where the formatter stops: turn a response into a spreadsheet with JSON → CSV, into markup with JSON → XML, or go the other way with CSV → JSON. And the neighbours run the same way, entirely in the browser: a JWT decoder, a SQL formatter across 11 dialects, Base64, a regex tester and a diff — none of which upload what you give them.

Use the JSON formatter and the rest of the developer tools — no sign-up, nothing uploaded, working offline once loaded.

Originally published on LK Forge.

Free Puzzle Games Online — and the Honest Answer to "Do They Help Your Brain?"

Lucian (LKB) — Thu, 03 Sep 2026 05:49:26 +0000

A quick mental break, a proper brain workout, or somewhere to put fifteen restless minutes — a good puzzle does all three, and the best ones cost nothing and need no download. Before the tour, though, the question everyone asks and few answer honestly: do puzzles actually keep your brain sharp?

The honest version of the research

The study that gets cited — usually with more confidence than it earns — is the 2019 PROTECT study (University of Exeter and King's College London), which looked at 19,078 adults aged 50 and over. The people who did puzzles most often scored on some cognitive tests like someone years younger.

That sounds decisive. It isn't. It's a correlation from self-reported data: sharper people may simply do more puzzles, rather than puzzles making them sharper — and the researchers said exactly that. So the honest pitch for a daily puzzle isn't "get smarter." It's a genuinely enjoyable, focused way to spend fifteen minutes, with a possible cognitive upside the science is still working out. That's plenty. A puzzle doesn't have to be medicine to be worth doing.

The games, by the thinking they train

With that settled, here's what's worth bookmarking — all free, all in the browser, no sign-up:

Pure logic — Sudoku is the anchor: classic 9×9, a gentler 6×6 for kids or a quick round, and a 16×16 hexadoku for a long sit-down, across Easy to Expert (with printable packs). Minesweeper and Connect 4 live here too.
Spatial & planning — a 15-puzzle and a block-unblock puzzle: pure move-planning, no clock.
Memory — Memory Match: flip cards, remember positions, clear the board in as few moves as you can.
Fast & satisfying — 2048 (one rule you learn in seconds) and Color Lines.
Word — a word-search maker and solver.
Unbeatable AI — Tic-Tac-Toe you cannot beat, only draw.

Where to start if you bounce off puzzles

Start with Sudoku on Easy, 2048, or Memory Match. Easy Sudoku leaves enough numbers filled in that every move is a simple check; 2048 has one rule; Memory Match has no real failure state. All three build confidence fast, and you can step up to Minesweeper, Connect 4 or harder Sudoku once the basics feel comfortable.

Play any of them at lkforge.com/games/puzzles — and if you'd rather have a machine finish a stubborn grid, the solver tools cover Sudoku, word search, crosswords, mazes, Minesweeper and more, all in the browser.

Originally published on LK Forge.

Tiled vs naive matrix multiplication: loop order was the bigger win

Lucian (LKB) — Wed, 02 Sep 2026 08:48:45 +0000

Syndicated from the original on lkforge.com, where the same numbers drive two inline charts. The matrix tools it links to are at lkforge.com/tools/math.

Tiling — splitting the matrices into cache-sized blocks — is the famous trick for making matrix multiplication fast, and it's the first optimization most guides reach for. So I wrote all three versions in C, compiled them the same way (cc -O2), and timed them against the thing you'd actually use in practice: a BLAS library. The numbers said something the tutorials usually skip: the biggest free win isn't tiling at all.

Everything below was measured on Apple Silicon (macOS), Accelerate BLAS backend. Absolute rates vary by machine — the pattern is what reproduces.

Four ways to multiply the same two matrices

Same matrices, same machine, four implementations, GFLOP/s (higher is faster):

n	naive `ijk`	reordered `ikj`	best tiled	BLAS (numpy `@`)
512	2.19	17.26	13.52	317.9
1024	2.64	16.73	14.83	410.1
2048	—	16.28	14.01	458.8

All four produced the identical result (checksums matched); only the speed differs. Three findings jump out at n=1024:

Loop order alone was 6.3× faster than naive (2.64 → 16.73), with no blocking at all.
Tiling was situational — my best tiled version (14.83) never beat the plain reordered loop on this hardware.
BLAS was another 24.5× ahead of my best loop (410 vs 16.73), and 155× the naive loop — and that gap is not cache tiling.

The free lunch: loop order

The naive order is for i, for j, for k: C[i][j] += A[i][k]·B[k][j]. The problem is the inner loop over k: A[i][k] walks along a row (contiguous, good), but B[k][j] walks down a column — every step jumps a full row ahead in memory. At n=1024 that's an 8 KB stride per multiply, so almost every access misses cache. The CPU spends its time waiting on memory, which is why naive sits at just 2.6 GFLOP/s. The multiplies are cheap; the memory stalls are the cost.

Swap the last two loops to for i, for k, for j and the inner loop becomes C[i][j] += a·B[k][j] with a = A[i][k] hoisted out. Now C[i][j] and B[k][j] both march along contiguous rows — unit stride. The hardware prefetcher and the compiler's auto-vectorizer both love that pattern, and the same arithmetic runs 6.3× faster. Not one line of blocking code; just touching memory in the order it's laid out.

Where tiling helps — and where it doesn't

Tiling computes the answer one small block at a time so a T×T patch of each matrix stays hot in cache while it's reused. That's a real effect, and you can watch it work — sweeping the tile size at n=1024:

tile size T	16	32	64	128	256
GFLOP/s	8.83	10.12	11.86	14.12	14.83

Throughput climbs steadily as the block grows — bigger tiles reuse more before eviction, right up until three tiles (3·T²·8 bytes) stop fitting in L2. But here's the honest part: every one of those bars is below 16.73 — the same loops reordered with no tiling at all.

Why the famous trick underperformed: this CPU has a large L2, and the compiler already auto-vectorizes the clean reordered inner loop into wide SIMD stores. A hand-written blocked loop adds index arithmetic and loop overhead the reordered version doesn't pay, and the cache pressure it relieves wasn't the bottleneck yet. Tiling earns its keep on smaller-cache CPUs, at much larger matrices, or — crucially — as one layer of a multi-level blocking scheme (registers → L1 → L2), which is exactly what real libraries do. As a bolt-on to a loop that already streams cache-friendly, it's a wash.

The lesson isn't "tiling is useless." It's measure on your hardware; the famous optimization isn't automatically the winning one.

The 24.5× that's left over

My best hand loop reached 16.73 GFLOP/s. numpy reached about 410 — still 24.5× more, from the same silicon. None of that remaining gap is cache tiling. It's SIMD (one instruction multiplying a whole vector at once), register blocking (keeping a tiny sub-block of the result in registers so it never touches memory mid-accumulation), multithreading across cores, and microkernels hand-tuned per CPU. Cache tiling is one rung on that ladder, not the ladder.

The practical takeaway is the oldest one in performance work: for real matmul, call the library — and spend your own effort only where no library exists.

Reproduce it

The three loops are below. Compile with cc -O2, time each, and divide 2·n³ by the seconds for GFLOP/s. Your absolute numbers will differ by machine, but the shape — naive slow, reorder ~6×, tiling situational, BLAS far ahead — reproduces.

// naive — inner loop reads B down a column (stride n): cache-hostile
void ijk(const double*A,const double*B,double*C,int n){
  for(int i=0;i<n;i++)for(int j=0;j<n;j++){
    double s=0;
    for(int k=0;k<n;k++) s+=A[i*n+k]*B[k*n+j];
    C[i*n+j]=s;
  }
}

// reordered — inner loop over j is unit-stride: the 6.3x win
void ikj(const double*A,const double*B,double*C,int n){
  for(int i=0;i<n*n;i++)C[i]=0;
  for(int i=0;i<n;i++)for(int k=0;k<n;k++){
    double a=A[i*n+k];
    for(int j=0;j<n;j++) C[i*n+j]+=a*B[k*n+j];
  }
}

// tiled — same math, blocked into T-sized patches for cache reuse
void tiled(const double*A,const double*B,double*C,int n,int T){
  for(int i=0;i<n*n;i++)C[i]=0;
  for(int ii=0;ii<n;ii+=T)for(int kk=0;kk<n;kk+=T)for(int jj=0;jj<n;jj+=T)
    for(int i=ii;i<ii+T&&i<n;i++)for(int k=kk;k<kk+T&&k<n;k++){
      double a=A[i*n+k];
      for(int j=jj;j<jj+T&&j<n;j++) C[i*n+j]+=a*B[k*n+j];
    }
}

The BLAS baseline is one line of Python — C = A @ B with numpy — timed the same way.

Original writeup with the charts: lkforge.com/blog/tiled-vs-naive-matrix-multiplication · try the browser matrix tools: matrix multiply · all math tools.

DEV Community: Lucian (LKB)

The North Star isn't the brightest star. It's not even in the top 40.

The correction

The actual brightest stars (as a share of Sirius)

Why the numbers run backwards

So why is Polaris famous?

Reproduce it

The UN voted to drop the Mercator map. Here's exactly how wrong it was, measured.

The headline: Greenland is not the size of Africa

The real top of the ranking (millions of km2)

Why the map lies, in one formula

Reproduce it

How Much Quality Do You Lose Compressing an Image? We Measured It on 24 Photos

The method

Diminishing returns are brutal

Format beats quality-cranking

The practical takeaway

Reproduce it

Dollar-Cost Averaging vs Lump Sum: What 75 Years of S&P 500 Data Shows

The headline result

But averages hide the interesting part

How it was measured

Check it yourself

Why a Tuner and Your Ear Disagree: The 13.7-Cent Compromise

Two definitions of "in tune"

How far apart they are

Why it has to be this way

What your tuner targets

Reproduce it

What the Average Big Five Result Actually Looks Like (n = 19,718)

Nobody is average on everything

The traits barely relate to each other

Which traits skew, and which spread

The honest caveat

Try it / reproduce it

We Ran Our Own Blog Through Our Word Counter: 22.1 Words a Sentence

The corpus

We write long sentences

Our crutch word wasn't on any list

The takeaway

How Much Grass Seed Do You Actually Need? It Swings 5 by Grass Type

The seeding rate runs from 1.5 to 8

What it means for a real lawn

One bag, wildly different coverage

Why: seed size, not area

Reproduce it

Does That "Free Online PDF" Tool Upload Your File? How to Tell.

How to tell an uploader from a client-side tool

The trade-offs, stated honestly

Read more

The Online JSON Formatter Guide: Formatter vs Validator, Privacy, and Four Time-Wasters

Formatter vs validator: don't confuse the two

Privacy is the one criterion you can't skip

Four mistakes that quietly waste hours

When JSON isn't the final form

Free Puzzle Games Online — and the Honest Answer to "Do They Help Your Brain?"

The honest version of the research

The games, by the thinking they train

Where to start if you bounce off puzzles

Tiled vs naive matrix multiplication: loop order was the bigger win

Four ways to multiply the same two matrices

The free lunch: loop order

Where tiling helps — and where it doesn't

The 24.5× that's left over

Reproduce it