# recursion Published articles for recursion. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## What algorithm did Windows XP use to choose your initial user picture? DevFeed: [What algorithm did Windows XP use to choose your initial user picture?]() Original publisher: [Read original article]() Author: Raymond Chen Published: 2026-09-09T14:00:00Z Content type: article Language: en Sources: [Raymond Chen]() Topics: [Algorithm](), [Randomizer](), [Windows](), [Filesystems]() Tags: [algorithm](), [files](), [history](), [old-new-thing](), [random](), [recursion](), [windows]() ### AI overview The article explains that Windows XP selected an initial user picture randomly from the Default Pictures directory using the current time as the random seed. It describes a one-pass reservoir-sampling algorithm, including its efficiency and behavior when files change during selection, with a 100-picture safety limit. ### Source excerpt It's random, really. The post What algorithm did Windows XP use to choose your initial user picture? appeared first on The Old New Thing. ## Too big to draw, but yet drawable DevFeed: [Too big to draw, but yet drawable]() Original publisher: [Read original article]() Author: Yehonathan Sharvit Published: 2026-07-06T09:00:00Z Content type: article Language: en Sources: [Klipse]() Topics: [ordering](), [structure]() Tags: [aboulafia](), [caustics](), [generative](), [math](), [permutation](), [permutations](), [random](), [ranking](), [recursion](), [visualization]() ### AI overview The third article in a series explains how Aboulafia's tserouf orders all permutations of a word and visualizes them by placing the permutations around a circle and connecting each word to its reversal. Because the full permutation space becomes too large to draw, the article samples chords and shows that they form recurring caustic curves visible at multiple scales. ### Source excerpt Aboulafia's Tserouf - Part 3 of 4 <- Previous: An elegant formulation, inspired by Bill Gates - Next: A wheel, the same forwards and backwards -> ## I tested nested subagents in Claude Code DevFeed: [I tested nested subagents in Claude Code]() Original publisher: [Read original article]() Author: Owain Lewis Published: 2026-06-17T14:03:13Z Content type: opinion Language: en Sources: [The AI Engineer]() Topics: [Claude Code](), [context window](), [Code](), [GitHub](), [Go](), [Pull Request](), [Code review]() Tags: [claude-code](), [coding](), [go](), [pipeline](), [pull-request](), [recursion](), [review](), [workflow]() ### AI overview The article tests nested subagents in Claude Code, including recursion depth and a three-level workflow of orchestrator, workers, and sub-workers. In a Go project, the workflow implemented a change, ran checks and tests, reviewed the result, fixed minor issues, and opened a pull request. ### Source excerpt Claude Code now let's you run nested subagents. But is it useful? ## How to Improve Coding Interview Performance with Personal Stories and Targeted Technical Practice DevFeed: [How to Improve Coding Interview Performance with Personal Stories and Targeted Technical Practice]() Original publisher: [Read original article]() Author: Brian Jenney Published: 2026-03-24T15:05:22Z Content type: opinion Language: en Sources: [Brian Jenney]() Topics: [coding](), [Development](), [Code](), [JavaScript]() Tags: [approach](), [career](), [coding](), [interviews](), [javascript](), [manager](), [recursion](), [software-engineer]() ### AI overview The author describes struggling with coding interviews despite being able to do the underlying job. They recommend cataloging personal work stories for recurring behavioral questions and focusing practice on recurring technical gaps. ### Source excerpt Five years ago, during an interview for a senior dev role, I had a panic attack. ## Designing a hierarchical Authorisation system DevFeed: [Designing a hierarchical Authorisation system]() Original publisher: [Read original article]() Author: Authorisation Published: 2025-09-20T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Actor](), [object](), [structure](), [service](), [properties]() Tags: [actor](), [apis](), [billing](), [finance](), [object](), [recursion](), [service](), [structure]() ### AI overview This article explains how to design a hierarchical authorization system for Goiter. It contrasts a flat mapping of users, objects, and actions with a hierarchical model in which groups can have multiple parents and inherit rules. The article notes that recursive parent lookup can reduce rule bloat, while assuming a maximum recursion depth of 10. ### Source excerpt . [Designing a Hierarchical Authorisation System](designing-a-hierarchical-authorisation-system-cover... ## Running Routing Protocols over Tunnels DevFeed: [Running Routing Protocols over Tunnels]() Original publisher: [Read original article]() Published: 2024-11-05T07:14:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Protocol (disambiguation)](), [BGP](), [IS-IS](), [MPLS-TE](), [MPLS VPN](), [evpn](), [VXLAN](), [Reason]() Tags: [bgp](), [evpn](), [ip-routing](), [is-is](), [mpls](), [mpls-te](), [ospf](), [protocol](), [recursion](), [routing](), [vxlan]() ### AI overview This article explains why routing protocols over tunnels can cause recursive routing and infinite encapsulation. It distinguishes traffic-engineering and IPsec tunnels from VPN designs, where routing protocols exchange customer and transport prefixes using separated address spaces or families. ### Source excerpt James got confused by a statement made by Hannes Gredler in his IS-IS book: Things behave really badly if the total IGP cost over the tunnel undermines the total topologies' cost. What happens next is that the tunnel "wraps" around itself, ultimately causing a meltdown of the entire network. Let's unpack that, starting with "Why would you need a tunnel?" Read more ... ## How a Geo Data Pipeline Bug Disrupted Skyscanner Flight Search DevFeed: [How a Geo Data Pipeline Bug Disrupted Skyscanner Flight Search]() Original publisher: [Read original article]() Author: Skyscanner Engineering Published: 2023-11-21T11:36:51Z Content type: article Language: en Sources: [Stories by Skyscanner Engineering on Medium]() Topics: [Graphs](), [data](), [dataset](), [systems](), [Kubernetes clusters]() Tags: [bug](), [data-pipeline](), [dataset](), [graph](), [issue](), [kubernetes-clusters](), [recursion](), [systems]() ### AI overview A bug in Skyscanner's geo data materialisation process made some locations their own parents, creating loops in the location hierarchy and disrupting flight search. The article explains the geo data model and the incident's technical context. ### Source excerpt How recursion brought down flight search at Skyscanner On 14th September, 2023 8:05 AM UTC (all timestamps in UTC) there was a critical bug in the output of our geo data pipeline which resulted in a number of geo locations being set as parents of themselves. This caused disruption to our service, and for this we're sorry. It gave us the opportunity to evaluate what went wrong, what we learned, and ways we could prevent a situation like this from happening again. Let's take a deep dive and explain things further. What is Geo Data? Geo data is a key dataset at Skyscanner which is used to provide systems, industry partners and travellers with a complete and accurate representation of the world. In simpler terms, any time you see an Airport, City, Region or Country used in Skyscanner, it's originating from this dataset. The most visible example across our offering can be seen when searching for flights where you will specify an airport, city or country for your journey. We use the geo data to populate origins/destinations and look for flights What was the issue? Skyscanner has been on a journey to upgrade our geo data set. At this time there are two versions, two geo models, running in parallel. Flights generally need to know about airports, cities, countries, contrary to other parts of the business where we need to model more complex relations such as districts, countries, islands, etc. Those relationships form a complex graph where locations are related to each others as parents and children. For this reason we kept our original "heritage" data set, merged it with our canonical dataset, our source of truth. We then basically generate (or reconstruct) our heritage dataset from the canonical data every day at 8am UTC. This generation is referred to as materialisation. The Materialisation Process On 14th September, a bug in the materialisation process updated some locations to be the parent of themselves. For example Scotland is now parent of Scotland. We've created a lo ## Arrow Core in Kotlin: Function Composition, Partial Application, and Recursive Functions DevFeed: [Arrow Core in Kotlin: Function Composition, Partial Application, and Recursive Functions]() Original publisher: [Read original article]() Published: 2022-11-28T00:15:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Functional programming](), [Library](), [Programming]() Tags: [functional-programming](), [generation](), [kotlin](), [library](), [programming](), [recursion](), [workshop-learning-programming]() ### AI overview A tutorial on Arrow Core, a Kotlin library for functional programming. It explains function composition, partial application, memoization, and recursive functions, including techniques for working with function arguments and preventing stack overflow in Fibonacci calculations. ### Source excerpt Learn about essential Arrow functions used for composition, memoization, recursion and functions generation. ## Personal Heatmaps DevFeed: [Personal Heatmaps]() Original publisher: [Read original article]() Author: J Evans Published: 2022-10-28T21:15:46Z Content type: tutorial Language: en Sources: [Strava Engineering]() Topics: [data](), [Algorithm](), [navigation](), [pixel](), [real-time](), [Google Maps](), [Website]() Tags: [algorithm](), [cycling](), [data](), [engineering](), [gis](), [google-maps](), [gps](), [heat](), [map](), [mapping](), [navigation](), [pixel](), [real-time](), [recursion](), [running](), [strava](), [zoom]() ### AI overview This article explains the algorithm behind Strava's Personal Heatmap, which renders an athlete's GPS activity as a frequency-based heatmap on an interactive world map. It focuses on Mercator projection and recursive map tiling, where 256x256 pixel tiles are served at different zoom levels for real-time navigation. ### Source excerpt This post discusses the algorithm behind Personal Heatmap, one of Strava's most acclaimed subscriber features. Product Overview The Personal Heatmap feature has been around in some form since 2015, but we gave it a major overhaul in 2020. For those unfamiliar, the heatmap is an aggregated view of an athlete's GPS-enabled activities on Strava. Activity data is rendered onto a map according to path traversal frequency; the more an athlete runs on a road, the brighter -- i.e. "hotter" -- that road shows up on the map. The result is a beautiful color gradient displaying the intricate web of past activities, unique to each athlete. The Personal Heatmap is displayed on an interactive world map, also known as a slippy map. Athletes can seamlessly zoom in and out or pan around to arbitrary views of the map, and their activity heat stays displayed the entire time. To enable this, we must provide a scheme for rendering and serving subsections of the world map on the fly. Enter map tiling. Mercator Projection & Map Tiling Map tiling is the practice of subdividing a map into many discrete images that can be stitched together and rendered as a single image in real-time during map navigation. The first step in choosing a tiling scheme is picking what world map to use. Enter, the Mercator Projection, the most commonly used projection of Earth as a flat, rectangular surface. We use this projection in all of our mapping products, including heatmaps. https://medium.com/media/d9e120d13950dd0f1bb4ee14108aa9a9/href Now, imagine a grid overlaying the Mercator projection. Each grid section is known as a tile, a pixel image with resolution 256x256. Every tile has an associated zoom level, and tiles are defined recursively according to this zoom level. A tile at a given zoom level can be subdivided into four equal sized tiles at a next zoom level. For example, Zoom level 0 displays the entire planet in a single 256x256 pixel image. Zoom level 1 displays the world in four 256x256 pixel images. ## Object-oriented or functional? Two ways to see the world DevFeed: [Object-oriented or functional? Two ways to see the world]() Original publisher: [Read original article]() Published: 2022-08-18T00:00:00Z Content type: opinion Language: en Sources: [Kt. Academy]() Topics: [Functional programming](), [Object-oriented programming (OOP)](), [Programming]() Tags: [fp](), [functional](), [immutability](), [inheritance](), [object-oriented](), [oop](), [polymorphism](), [recursion](), [workshop-learning-programming]() ### AI overview This opinion article compares object-oriented programming and functional programming as ways of thinking about program design, rather than merely collections of features. It uses different ways of viewing a bedroom--as objects or actions--to illustrate the distinction while acknowledging that modern languages commonly support both styles. ### Source excerpt The difference between the OOP and FP paradigms is deeply rooted in how we see the world. A few words on the philosophy of both approaches. ## Making unwinding through JIT-ed code scalable - The b-tree DevFeed: [Making unwinding through JIT-ed code scalable - The b-tree]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2022-06-26T08:56:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [Data structures](), [Concurrency](), [Concurrent Programming](), [Code]() Tags: [code](), [data-structure](), [implementation](), [memory](), [node](), [object](), [recursion](), [structure](), [synchronization]() ### AI overview This article explains the data-structure and infrastructure portions of a scalable unwinding system that uses a B-tree for fast lookup and data locality. It describes node organization, invariants, fence keys, helper functions, optimistic lock coupling, memory reclamation through a free list, and recursive destruction; insert, remove, and lookup operations are deferred to the next article. ### Source excerpt This article is part of the series about scalable unwinding that starts here. We use a b-tree because it offers fast lookup, good data locality, and a scalable implementation is reasonable easy when using optimistic lock coupling. Nevertheless a b-tree is a non-trivial data structure. To avoid having one huge article that includes all details of the b-tree, we just discuss the data structure themselves and some helper functions here, the insert/remove/lookup operations will be discussed in the next article. A b-tree partitions its elements by value. An inner node contains a sorted list of separator/child pairs, with the guarantee that the elements in the sub-tree rooted at the child pointer will be <= the separator. The leaf nodes contains sorted lists of (base, size, object) entries, where the object is responsible for unwinding entries between base and base+size. An b-tree maintains the invariants that 1) all nodes except the root are at least half full, and 2) a leaf nodes have the same distance to the root. This guarantees us logarithmic lookup costs. Note that we use fence-keys, i.e., the inner nodes have a separator for the right-most entries, too, which is not the case in all b-tree implementations: // The largest possible separator value static const uintptr_t max_separator = ~((uintptr_t) (0)); // Inner entry. The child tree contains all entries <= separator struct inner_entry { uintptr_t separator; struct btree_node *child; }; // Leaf entry. Stores an object entry struct leaf_entry { uintptr_t base, size; struct object *ob; }; // node types enum node_type { btree_node_inner, btree_node_leaf, btree_node_free }; // Node sizes. Chosen such that the result size is roughly 256 bytes #define max_fanout_inner 15 #define max_fanout_leaf 10 // A btree node struct btree_node { // The version lock used for optimistic lock coupling struct version_lock version_lock; // The number of entries unsigned entry_count; // The type enum node_type type; // The payload union { / ## Advent of Kotlin Solutions DevFeed: [Advent of Kotlin Solutions]() Original publisher: [Read original article]() Published: 2022-01-02T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Programming](), [clustering](), [JSON]() Tags: [algorithms](), [clustering](), [json](), [kotlin](), [pattern-matching](), [recursion](), [sealed-class](), [workshop-learning-programming]() ### AI overview This article presents Kotlin solutions for Advent of Kotlin 2021 exercises, including JSON stringification, generating well-formed parentheses, tree algorithms, and k-means clustering. It discusses recursion, sealed classes, smart casting, and Kotlin functions used in the solutions. ### Source excerpt Solutions to the Advent of Kotlin! ## Taming Deep Recursion DevFeed: [Taming Deep Recursion]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2020-11-22T16:50:00Z Content type: tutorial Language: en Sources: [Database Architects]() Topics: [Data structures](), [SQL](), [Parser](), [Code](), [Exception](), [Compiler]() Tags: [code](), [compiler](), [crash](), [data-structures](), [exception](), [recursion](), [snippet](), [sql]() ### AI overview The article examines stack overflows caused by recursive traversal of very deep SQL expression and algebra trees. It discusses stack-usage checks, explicit-stack iteration, and compiler-supported split stacks as ways to handle unusually deep inputs while preserving simpler recursive code. ### Source excerpt When operating on hierarchical data structures, it is often convenient to formulate that using pairwise recursive functions. For example, our semantic analysis walks that parse tree recursively and transforms it into an expression tree. This corresponding code looks roughly like this: unique_ptr analyzeExpression(AST* astNode) { switch (astNode->getType()) { case AST::BinaryExpression: return analyzeBinaryExpression(astNode->as()); case AST::CaseExpression: return analyzeCaseExpression(astNode->as()); ... } } unique_ptr analyzeBinaryExpression(BinaryExpAST* astNode) { auto left = analyzeExpression(astNode->left); auto right = analyzeExpression(astNode->right); auto type = inferBinaryType(astNode->getOp(), left, right); return make_unique(astNode->getOp(), move(left), move(right), type); } It recursively walks the tree, collects input expressions, infers types, and constructs new expressions. This works beautifully until you encounter a (generated) query with 300,000 expressions, which we did. At that point our program crashed due to stack overflow. Oops. Our first mitigation was using __builtin_frame_address(0) at the beginning of analyzeExpression to detect excessive stack usage, and to throw an exception if that happens. This prevented the crash, but is not very satisfying. First, it means we refuse a perfectly valid SQL query "just" because it uses 300,000 terms in one expression. And second, we cannot be sure that this is enough. There are several places in the code that recursively walk the algebra tree, and it is hard to predict their stack usage. Even worse, the depth of the tree can change due to optimizations. For example, when a query has 100,000 entries in the from clause, the initial tree is extremely wide but flat. Later, after we have stopped checking for stack overflows, the optimizer might transform that into a tree with 100,000 levels, again leading to stack overflow. Basically, all ## Deep recursion with coroutines DevFeed: [Deep recursion with coroutines]() Original publisher: [Read original article]() Author: Roman Elizarov Published: 2020-04-25T20:33:55Z Content type: tutorial Language: en Sources: [Stories by Roman Elizarov on Medium]() Topics: [Coroutines](), [Kotlin](), [Data structures](), [Programming]() Tags: [coroutine](), [coroutines](), [data-structures](), [exception](), [jvm](), [kotlin](), [kotlin-coroutines](), [recursion]() ### AI overview This tutorial explains how Kotlin coroutines can be used to handle deeply recursive functions. Using a 100,000-node binary tree as an example, it shows that ordinary recursion can exhaust the thread call stack and lead to a StackOverflowError, then introduces rewriting the algorithm to use heap memory instead. ### Source excerpt Photo by Riccardo Pelati on Unsplash Kotlin Coroutines are typically used for asynchronous programming. However, the underlying design of coroutines and their implementation in Kotlin compiler are quite universal, solving problems beyond asynchronous programming. Let's take a look at one such problem that can be elegantly solved with coroutines-- writing deeply recursive functions. Setup Consider a tree data structure. For this example, let's use this simple binary tree where each Tree node has a reference to its left and right children: class Tree(val left: Tree?, val right: Tree?) The depth of the tree is defined as the length of the longest path from its root to its child nodes. It can be computed by the following recursive function: fun depth(t: Tree?): Int = if (t == null) 0 else maxOf( depth(t.left), // recursive call one depth(t.right) // recursive call two ) + 1 The logic here is straightforward. The depth is simply the maximum of the depth of the left and right children plus one, with the special case of zero when the tree is empty. Recursion is a great tool for working with tree-like data structures, but there is a catch. Let's generate a deep tree containing 100K nodes. Start with a leaf node Tree(null, null) as a seed and repeatedly generate parent nodes that link to the previous node as their left children: val n = 100_000 val deepTree = generateSequence(Tree(null, null)) { prev -> Tree(prev, null) }.take(n).last() This is not a particularly big data structure. It occupies less than 2MiB of memory, which is not much at all for a modern machine with gigabytes of available memory. Now, let's try to use our depth function on it: https://medium.com/media/f919e36404c4bf79aef919395ab51918/href If you run it in Kotlin Playground you'll get "Your program produces too much output!" message. If you run the same code on your local machine you'll see what kind of output that is: Exception in thread "main" java.lang.StackOverflowError at FileKt.depth(File.kt:5) ... / ## Yet another explanation of the Quicksort algorithm DevFeed: [Yet another explanation of the Quicksort algorithm]() Original publisher: [Read original article]() Published: 2019-11-22T23:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [Sorting](), [Algorithm](), [C](), [Go Language](), [Haskell](), [Python]() Tags: [algorithm](), [c](), [go-language](), [partitioning](), [python](), [recursion](), [sorting]() ### AI overview An explanation of the Quicksort algorithm, contrasting a mean-based partitioning approach with randomized and classic in-place implementations. It also discusses recursive partitioning and switching to another sorting algorithm for small arrays. ### Source excerpt Yet another explanation of the Quicksort algorithm ## Kotlin-Java Interop Can Cause Recursive Property Calls DevFeed: [Kotlin-Java Interop Can Cause Recursive Property Calls]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2018-11-01T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Kotlin](), [Java](), [Android Studio]() Tags: [android-studio](), [blogs](), [java](), [kotlin](), [legacy](), [legacy-code](), [puzzle](), [recursion](), [stackoverflow]() ### AI overview This article explains how Kotlin-Java interop can cause a property access to call itself recursively when inheriting from a Java class. It examines the resulting bytecode and notes that Android Studio can warn about the recursion. ### Source excerpt Java interop is one of the best features of the Kotlin language, yet sometimes this also can cause unforeseen issues... Puzzle # Disclaimer, the example below is a consequence of legacy code and only serves to demonstrate a Kotlin puzzler. ## Let's Build A Simple Interpreter. Part 6. DevFeed: [Let's Build A Simple Interpreter. Part 6.]() Original publisher: [Read original article]() Author: Ruslan Spivak Published: 2015-11-02T12:00:00Z Content type: tutorial Language: en Sources: [Ruslan Spivak]() Topics: [Parsing](), [syntax](), [Code]() Tags: [blog](), [code](), [expression](), [lexer](), [recursion](), [syntax](), [tokens]() ### AI overview This tutorial extends an arithmetic-expression grammar to support parenthesized expressions with arbitrarily deep nesting. It updates the lexer and interpreter to evaluate expressions containing integers and arithmetic operators. ### Source excerpt Today is the day :) "Why?" you might ask. The reason is that today we're wrapping up our discussion of arithmetic expressions (well, almost) by adding parenthesized expressions to our grammar and implementing an interpreter that will be able to evaluate parenthesized expressions with arbitrarily deep nesting, like the expression ... ## Reducers explained (through Python) DevFeed: [Reducers explained (through Python)]() Original publisher: [Read original article]() Published: 2013-07-07T00:00:00Z Content type: tutorial Language: en Sources: [Adam Bard]() Topics: [Python](), [Clojure](), [Elixir](), [Library](), [Code](), [Programming]() Tags: [clojure](), [code](), [collections](), [elixir](), [filter](), [functional](), [libraries](), [list](), [pipeline](), [programming](), [python](), [recursion](), [reduce]() ### AI overview This tutorial explains reducers through Python. It introduces reduce or fold as a fundamental collection operator, shows how map and filter can be built from it, and describes how reducers combine collection operations into a single pass instead of repeatedly iterating over a list. ### Source excerpt Last year, Clojure introduced a new library called core.reducers, which represented a new, efficient way to deal with operations across collections in functional languages. It's since been picked up by Elixir, and libraries have been written for some other languages. Today, I want to explain a bit about what reducers are, why they exist, and how they can be more efficient than other functional methods of handling collections, and help you write your code more prettier. ## Seven Languages in Seven Weeks: Erlang DevFeed: [Seven Languages in Seven Weeks: Erlang]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2012-12-18T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Erlang](), [Concurrency](), [function](), [pattern matching](), [Processes]() Tags: [concurrency](), [erlang](), [function](), [pattern-matching](), [process](), [recursion]() ### AI overview A beginner documents working through Erlang exercises from "Seven Languages in Seven Weeks," covering recursion, pattern matching, list comprehensions, regular expressions, concurrency, process monitoring, and process restarts. The author notes that some solutions may contain errors while learning the language. ### Source excerpt So, I just bought "Seven Languages in Seven Weeks". I've read the Ruby chapter, not a big deal at all, so I skipped it. I also skip Io, Prolog and Scala (for now), and then, fall in Erlang! ## A Spoonful of Python (and Dynamic Programming) DevFeed: [A Spoonful of Python (and Dynamic Programming)]() Original publisher: [Read original article]() Published: 2012-01-12T23:11:26Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [Python](), [Programming](), [Algorithm]() Tags: [dynamic-programming](), [fibonacci](), [memoized-recursion](), [primer](), [python](), [recursion]() ### AI overview A Python primer covering built-in types such as lists, tuples, and dictionaries, with examples involving Fibonacci numbers and optimal coin change. It introduces dynamic programming and compares inefficient recursive and recursionless approaches. ### Source excerpt This primer is a third look at Python, and is admittedly selective in which features we investigate (for instance, we don't use classes, as in our second primer on random psychedelic images). We do assume some familiarity with the syntax and basic concepts of the language. For a first primer on Python, see A Dash of Python. We'll investigate some of Python's useful built-in types, including lists, tuples, and dictionaries, and we use them to computing Fibonacci numbers and "optimal" coin change. ## Turing Machines and Conway's Dreams DevFeed: [Turing Machines and Conway's Dreams]() Original publisher: [Read original article]() Published: 2011-06-30T20:50:04Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [Automaton]() Tags: [cellular](), [cellular-automata](), [computability-theory](), [computational-complexity](), [conway](), [infinite](), [life](), [mathematics](), [patterns](), [period](), [programming](), [recursion](), [theory](), [turing-machine](), [turing-machines]() ### AI overview The article examines Conway's Game of Life patterns that do not stabilize, including Gosper's glider gun and puffers that produce continuing activity. It connects these patterns to computability, explaining that infinite looping is necessary for Turing-complete computation. ### Source excerpt Additional Patterns Last time we left the reader with the assertion that Conway's game of life does not always stabilize. Specifically, there exist patterns which result in unbounded cell population growth. Although John Conway's original conjecture was that all patterns eventually stabilize (and offered $50 to anyone who could provide a proof or counterexample), he was proven wrong. Here we have the appropriately named glider gun, whose main body oscillates, expelling a glider once per period. ## Well Orderings and Search DevFeed: [Well Orderings and Search]() Original publisher: [Read original article]() Published: 2011-06-14T11:18:04Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [Algorithm](), [Sorting](), [ordering](), [implementation]() Tags: [algorithm](), [axiom-of-choice](), [binary-search](), [mathematica](), [mathematics](), [optimization](), [ordering](), [pseudocode](), [recursion](), [sorting](), [well-ordering]() ### AI overview This tutorial explains binary search on sorted lists, including its recursive structure and O(log n) runtime. It then introduces strict total and well orders to explain why sorting and comparison work. ### Source excerpt Binary Search Binary search is perhaps the first and most basic nontrivial algorithm a student learns. For the mathematicians out there, binary search is a fast procedure to determine whether a sorted list contains a particular element. Here is a pseudocode implementation: # Binary Search: # Given a list L, sorted via the total order <, and a sought # element x, return true iff L contains x. function binarySearch(L, x, <): # base case if(length(L) == 1): return L[0] == x middleIndex = floor(length(L) / 2) if (L[middleIndex] == x): return true # inductive step, with ellipsis notation meaning slices of L # from the beginning and to the end, respectively if (x < L[middleIndex]): return binarySort(L[. ## Erlang talk at London Hackspace DevFeed: [Erlang talk at London Hackspace]() Original publisher: [Read original article]() Author: {"image"=\>"rj-headshot.jpg", "greetings"=\>nil} Published: 2009-10-08T05:00:00Z Content type: article Language: en Sources: [Richard Jones]() Topics: [Erlang](), [Programming](), [Functional programming](), [Processes]() Tags: [code](), [distributed-systems](), [erlang](), [functional-programming](), [hackspace](), [london](), [messages](), [mochiweb](), [playdar](), [processes](), [recursion](), [state](), [talk](), [uncategorized](), [upgrade]() ### AI overview This article recaps an introductory Erlang talk at a London Hackspace meetup. It explains Erlang's use for scalable, reliable distributed systems and demonstrates processes, message passing, recursive state management, hot code reloading, and gen_server. ### Source excerpt Last night I gave an "Intro to Erlang" talk at a London Hackspace meetup. I did a quick audience survey first: About 75% did "web programming" (ruby,python,php,etc). Around 30% admitted to regularly using C/C++/Java or desktop/mobile app development. Less than 10% had much experience with functional programming.