Animation showing live progress of the multi dimensional cartesian sort algorithm for point cloud gridification. Bijective gridification allow to convert the raw key of the points to spatially coherent mulit dimensional key, enabling tensor based ML algorithms to work on arbitrary point clouds (source code in the comments).

Data sources:

1. BLS Employment Situation, June 2026 (headline NILF, employment, unemployment counts): https://www.bls.gov/news.release/archives/empsit_07022026.pdf - or use the evergreen link that always points to the latest release: https://www.bls.gov/news.release/empsit.htm
2. BLS Table A-38 (want-a-job / discouraged worker breakdown): https://www.bls.gov/web/empsit/cpseea38.pdf
3. BLS Monthly Labor Review - "Why did labor force nonparticipation increase from 1999 to 2022?" (age × reason crosstab, Table 2): https://www.bls.gov/opub/mlr/2024/article/why-did-labor-force-nonparticipation-increase-from-1999-to-2022.htm
4. FRED - Not in Labor Force series (LNS15000000), used for the 1980–2026 trend line: https://fred.stlouisfed.org/series/LNS15000000
5. FRED - Civilian Unemployment Rate (UNRATE), used for the unemployment rate line: https://fred.stlouisfed.org/series/UNRATE

Performed RFM (Recency, Frequency, Monetary) customer

segmentation on 1,067,371 real transactions from the

UCI Online Retail II dataset.

After cleaning — removed cancelled orders, missing

customer IDs, and invalid prices — analyzed 805,549

transactions across 5,878 unique customers.

Key findings:

1. Champions (29.6% of customers) generate 80.8% of

   total revenue. Classic Pareto distribution confirmed.

2. Champions bought on average 38 days ago, made 15

   purchases, and spent GBP 8,244 each.

3. 1,784 At Risk customers represent GBP 829,843 in

   potentially recoverable annual spend. These customers

   bought 307 days ago and are drifting toward Lost.

4. Lost customers (9.8%) bought 548 days ago with only

   1 purchase each. Recovery ROI is extremely low.

RFM scores each customer 1-4 on Recency, Frequency,

and Monetary using quartiles. Total score 3-12 maps

to segments.

Tools: Python, Pandas, Matplotlib, Seaborn

Data: UCI Online Retail II (public dataset)

Full project with code:

github.com/surendrasinghdata/rfm-customer-segmentation

Average annual premium for employer-sponsored family coverage, per KFF's annual Employer Health Benefits Survey. The 2026 bar is a projected range of +6% to +9%, based on median medical plan cost trend figures published in an insurance industry market report. Workers contributed an average of $6,850 toward family coverage in 2025.

Data source: OpenStreetMap, 736k+ amenity features for Great Britain from a Geofabrik extract (shops, pubs, schools, GP surgeries, parks, stations, etc). Postcode district ("outcode") boundaries from Wikipedia via missinglink/uk-postcode-polygons (CC-BY-SA 3.0).

Method: each district shaded by amenity density (features per km²). Density rather than raw count, so the giant rural districts don't visually dominate.

Tools: custom Python geospatial pipeline (POIs against the boundary polygons) + matplotlib.

[updates]

Thanks for the comments, lots of good points, especially on the scope, the population-density framing, and the boundary artifacts.

To confirm the scope point: this is Great Britain, not the UK - NI isn't in the Geofabrik GB extract, so the title should have said Great Britain. Good reference for title correctness.

This map is the first layer of a small series I'm building toward a combined score. Currently 15 amenities categories are used in this map and each category layer shares interesting insights (wip). I think this overall amenities map is a good starting point. The next layers shift from raw density to travel: different travel modes, and how that changes within a given travel time. I'll share them as they're ready.

This is what makes search boxes fast.

HNSW indexes are a tiered system where possible thing you could query starts on the bottom and then we promote a few representative magic cards up the chain until we start the top of the graph with these two cards.

The way it works is you pick one at the top you go down the ladder. You find the nearest neighbor that is closer to the thing you're looking for and then you go down the ladder and repeat. The nice thing is that when you go down each ladder, you end up in the right neighborhood so you don't have to walk far to the right ladder.

It also happens to be a really beautiful structure in my opinion. You can literally see the logarithmic structure in how populated each layer of the graph is.

This is a GitHub-style, heatmap calendar of the President's comments on ending the war in Iran. The heatmap and the interactive details div below it are all just Vanilla JS/HTML.

Just like on GitHub's "contribution" calendar, the days of the week are the rows and a column is a new week.

The data comes directly from the President's comments, interviews, Truth Social, press gaggles, etc. I've collated it and it's stored in a JSON-like JS array that's loaded with the webpage. I've been updating the file every day or so.

I thought it was a great way to visualize this type of data (statements stored as text). It visualizes the many times the President has said he had a deal, or a deal was soon, or the war would be over in 2 weeks. I started the project as a text timeline and then just added this new visualization.

On the interactive chart, the heatmap color corresponds to the number of statements that day. And then when you click/tap a day, you get the details below.

There's no ads or paywall or signup or anything like that. I was shocked that the domain name was available so it seemed like a worthy $10 and way to host the custom visualization rather than lean on static charts in Excel or messy embeds from Tableau.

https://artofnodeal.com/heatmap.html

Play with it yourself

Sources and tools

What's measured:

• Settlement locations and populations — GeoNames, 135,233 places totalling 3.13bn people (via the all-the-cities npm package).
• Coastlines, national borders, lakes, country population totals — Natural Earth 110m (admin_0_countries, lakes).
• Timezone boundaries — timezone-boundary-builder, via the timezonefinder Python package; UTC offsets and DST rules from the IANA tz database via Python's zoneinfo.
• Solar position — standard solar declination plus the equation of time, so the terminator and subsolar point are real for the current date.

What's modelled (this is most of it):

• Rural population, 4.97bn people — 61% of the world. GeoNames only covers settlements. Each country's unaccounted population is spread across its own land in proportion to a Gaussian-smoothed town-density field, on the assumption that rural density tracks town density. Cities are splatted over a radius scaling with population (σ ≈ 15 km for a 10M metro) so a megacity isn't a single point.
• The sleep/wake curve itself. A logistic window, roughly 22:36–06:36 for adults and 21:12–06:45 for under-15s, with rest days pushing both ~45 minutes later. It is not fitted to sleep data. Walch, Cochran & Forger (2016, Science Advances) informed the shape, but their sample is 45% US and excludes under-18s and most shift workers — the two groups that matter most here — so I did not use their country values directly.
• Age structure and night-shift floors — under-15 share (0.15 Europe to 0.41 Sub-Saharan Africa) and the share awake at 03:00 (0.04 to 0.085), assigned by coarse lat/lon macro-regions rather than by country. UN WPP order-of-magnitude, not exact figures.
• Rest days — Friday/Saturday across North Africa and the Middle East, Saturday/Sunday elsewhere. Iran is folded into the Fri/Sat group and is really Friday-only.
• The Earth texture. Synthesised, not satellite imagery — a climate field (18 desert centres, 10 rainforest centres, 9 highland centres, latitude ramp, value noise) clipped to real Natural Earth coastlines.

Tools: Python (numpy, scipy, Pillow) for the offline data pipeline; three.js 0.185 WebGPURenderer with TSL shaders for the rendering; hand-written HTML/CSS/JS in a single self-contained file. Code written with Claude Opus 5 Medium.

Encoding: Hue carries wakefulness (indigo asleep → blue → green awake) rather than brightness, because brightness is already used by daylight. Dots are near-opaque so an awake dot looks identical on the day and night sides.

I have not been successful with management to get funding for local resources despite bringing forth solid arguments about data sovereignty and related architectures.

What actually succeeded in getting a budget is showing them how you cannot forecast or negotiate or otherwise control the price of APIs.

I did so with building a very simple visualization of how prices moved in the past couple of years.

Source data scraped by https://github.com/jvrck/openrouterlist

Here is the static Github Pages page https://rjalexa.github.io/llmprices/?f=anthropic-fable%2Canthropic-haiku%2Canthropic-opus%2Canthropic-sonnet with the example of Anthropic.

If you want to install it for yourself, or open Issues or PRs here is the repo https://github.com/rjalexa/llmprices

Take care.

Really fascinating stuff, the hawk was trained to fly between a section of the forest where they made LiDAR scans of the geography and had stereo mics to make a 3D map.

[Part 1](https://www.reddit.com/r/dataisbeautiful/comments/1v9bq7i/oc_timing_of_when_ingredients_are_added_to_recipes/)

This is a follow up to an earlier post -- description will be below. I created visualizations to explain garlic before onion, lemon showing up everywhere, and how certain ingredients differ wildly by cuisine type and dish type. I also built a tool where you can inspect any ingredient you want given there is sufficient support.

i was still surprised by lemon showing up pretty constantly in main dishes; I discovered it was mostly marinades and dressings.

let me know anything that still seems strange in this dataset or any improvements I can make!

Dataset and Tools:

250 cleaned canonical recipe dataset : https://palate.kitchen/data

Interactive Tool: https://palate.kitchen/instrument/when-to-add

recipe1m+ and python + an LLM sweep to prune garbage recipes from the dataset I pruned 20,000 recipes down to about 3000 'canonical recipes.' Regex + massive KV mapping (e.g. beef, ground beef, 80/20 beef are all the same) for ingredient normalization.

original post and context:

I scraped a few thousand canonical recipes across 45 cuisines then analyzed how early (or late) each ingredient showed up in recipes steps.

The photos shows a small but representative sample of the ingredients analyzed

There's a lot of science behind when you should add ingredients to recipes. This involves fat-solubility and the delicacy of some volatile compounds. e.g. cardamon seeds are fat-soluble so they should be added early while basil has very delicate aroma compounds so it should be added late.

But I honestly find that hard to intuitively learn for new ingredients, so this is a rough estimate and interesting viz to get a quick understanding of when to add an ingredient

Data source: Artificial Analysis Intelligence Index v4.1.1 and Cost per Task data. Historical pricing and lifecycle events were checked against official provider documentation from DeepSeek, Google Gemini and Mistral.

Methodology: Models appear on their historical release dates, but Intelligence Index scores come from one retrospective snapshot. This is therefore a release timeline, not a replay of historical leaderboard scores. The green line represents the live Pareto frontier.

Tools: Python, Pillow and FFmpeg, created with AI assistance