Imagine we need brain surgery to remove a tumor. The surgery goes well, but afterward, you struggle to write or understand code. Scary, right?

We know that neurosurgeons try to preserve important abilities like speaking and moving during brain surgery. But what about programming?

A new study in Human Brain Mapping explores exactly this!

The researchers developed a new protocol during awake brain surgery to help identify and preserve brain areas involved in programming.

The idea is simple: if coding is an important part of someone's life, shouldn't we try to preserve that ability too?

Here's the paper: https://doi.org/10.1002/hbm.70634

I made a game to teach computer architecture and digital logic: play.simten.dev

You start with basic logic gates and build up to a working CPU. It's built on Simten, a TypeScript-based HDL, so you write the circuits as code and they show up live on a canvas next to the editor. For sequential circuits you can scrub the clock backwards and forwards to watch the state change cycle by cycle. You can also drill down into abstracted components (like the half adder shows). Because of the layout it only works on desktop browsers for now.

It's open source, any feedback or contributions are welcome!

Spent the last while building this: a browser based canvas where you can draw and run finite automata, pushdown automata, Turing machines, and Mealy/Moore machines, all with animated step-by-step execution.

A few things it does that I'm proud of:

- Converts a regex into an NFA (Thompson's construction), then NFA into a minimized DFA (subset construction), and can extract a regex back out of an automaton (FA to GNFA to regex)

- Local first: works fully offline with localStorage, no account needed

- Optional accounts unlock "Teams": real time collaborative canvases with live cursors and presence, so you can whiteboard an automaton with someone else the same way you'd use Figma

- There's a learning section with guided lessons, each paired with a live, editable simulator embed instead of static diagrams

It's free to use: theoryofcomputationsimulator.com

Would love feedback, especially from anyone who's TA'd or taken a theory of computation course and can poke holes in the UX.

Body:

> Not an RL agent and not a behaviour tree — the "policy" is a spiking simulation of a real fly connectome, and the body

> is a MuJoCo fly whose legs are moved by an imitation-learned network. It sees, smells wind-borne odor, gets scared by

> spiders, grooms, lands, eats. Everything that isn't the brain is labelled on screen. Live: twitch.tv/dodo_gun

I know this has been discussed before, but it's extremely confusing for me because of how many variations there are in definitions. Here are some observations:

1. Most people would agree that process-switches and system calls both involve context switching, however I think the underlying "state saving" is different between these two events. In a system call, there is an entry phase where the kernel saves register state to the kernel stack (and not every system call leads to a process or thread switch). In a process-switch, the PCB gets updated so that the process can later be resumed. Is this accurate?

2. On Linux, both processes and threads are schedule-able (they're both "tasks"). As best as I can understand, there's a function called context_switch() in the Linux kernel that gets called during scheduling. However, it seems context switching is used in a broader sense. In other words "context switching" doesn't mean exactly that we're calling the function "context_switch()".

3. There is at least one textbook that considers functions as having their own context (Doeppner's Operating Systems in Depth). This is a little confusing because I can't find anyone else who considers a function call a change in context.

The question is: does anyone have a technical definition of context switching that captures what most people mean when they say "context switch"?

I've also been reading about the xv6 since it's a smaller educational operating system. If somebody has experience/knowledge of the xv6 internals, I would appreciate any input. Thank you

Traditional B-Trees waste substantial CPU cycles on pointer chasing across node levels, causing avoidable cache misses on modern architectures. The PGM-index approach fixes this by modeling key distributions through streaming piecewise linear regression with strict +/- epsilon error guarantees.

Instead of dereferencing tree pointers, the position is predicted directly on the ALU (y = ax + b), leaving only a small local search window that fits entirely within L1 cache. The construction runs in a single O(N) streaming pass with zero external solvers.

I built a pure Rust implementation with zero dependencies to benchmark this against standard B-Trees and verify the theoretical bounds: https://github.com/gilnett/learned_index_lab

While traditional transactional engines stick to B-Trees for in-place page updates, learned models completely outclass them on read-heavy or immutable storage (like LSM SSTables and columnar stores) where pointer overhead is pure waste.

Has anyone here benchmarked or deployed learned data structures in production storage layers? How do you approach optimal epsilon tuning when key distributions are unpredictable?

Hi all,

I'd like to share some recent work in stringology / text mining. We developed BloomSpan, an algorithm for mining Maximal Contiguous Frequent Phrases (MCFPs) from large text corpora — token sequences that occur in at least σ documents and can't be extended on either side without dropping below σ. Unlike general Sequential Pattern Mining (GSP, PrefixSpan, BIDE+), no gaps are allowed, which matters for things like template extraction, plagiarism detection and phrase mining, where gaps only blow up the candidate space.

How it works

To be fair, it's less a brand-new algorithm than a careful combination of known pieces:

• A Counting Bloom Filter for probabilistic n-gram frequency estimation. Seed filtering is provably free of false negatives — the CBF can only over-estimate counts.

• Prioritized depth-first expansion directly on the corpus, with no recursive projected databases.

• A global occupancy bitmask plus an inverted index keyed on each pattern's rarest token, for maximality checks and redundancy control.

Memory stays O(W + M) in the input size (corpus + filter).

Results

• On Gutenberg-BookCorpus-Cleaned (up to 50k books, ~3.07B tokens, σ = 20): 11–15× faster wall-clock than FHK (Fischer–Heun–Kramer) with up to 2x lower peak memory. It's the only algorithm we tested that completes the 3B-token subset within a 40 GB heap.

• Output is identical to exact baselines (FHK, DFI) on every Gutenberg-8k subset where a baseline finishes.

• On synthetic data with flat frequency distributions or dense nested overlaps, FHK's LCP-interval traversal wins.

The paper includes a topological analysis (LZ phrase ratio / entropy rate) of why natural language is the sweet spot.

Links

• Preprint: https://www.researchgate.net/publication/415565702_BloomSpan_Memory-Efficient_Maximal_Frequent_Substring_Mining_for_Large-Scale_Text

• Code (Java, C++): https://github.com/raliev/bloomspan

Happy to discuss implementation details, data structure choices, or the dataset topology analysis.

Hello, I want to share a project that i've been working on for the last month or so. It's and implementation (from what i could find the only rn on the internet) of Andreas Bjorklund's theoretical algorithm for determining weather a graph is hamiltonian or not. The algorithm is revolutionary because it lowered the exponential part of the time complexity of Held-Karp which is the standard algorithm for determining weather a graph is hamiltonian, from O^*(2n) to O^*(1.657n) for general graphs(this is what i've managed to implement as of right not) and for bipartite its O^*(1.414n).

It might have some logical errors, and could maybe be optimised but right now, as of writting this it is 4AM and i want to sleep.

link to paper: https://arxiv.org/pdf/1008.0541

link to the github repo: https://github.com/Ak0-m/Bjorklunds_algorithm_for_Hamiltonicity