标签：#algo

Building a personalization engine for a multi-format content feed, without machine learning, and the testing process that forced us to rebuild it. TL;DR We run a collaborative cultural curation platform (think: user-submitted recommendations for movies, books, games, music, and long-form posts, all mixed into one feed) on a fairly ordinary PHP + MySQL stack. Over about a year we went through two full generations of the feed ranking algorithm. The first version solved the obvious problem (stop being purely chronological) but quietly failed at real personalization. The second version fixed that by rethinking what "user taste" even means, moving scoring out of SQL and into application code, and adding a layer of post-ranking business rules. This post walks through both generations, why the second one had to happen, and how we actually tested and calibrated a feed ranking system without a data science team or an ML pipeline. No exact weights, table names, or formulas below — just the engineering story. The starting problem: one feed, five content shapes Before personalization is even on the table, a multi-format feed has a normalization problem. Movies, books, games, music, and editorial posts live in different tables, with different columns, different publishing cadences, and engagement numbers on completely different scales. "1,000 likes" on a music post and "1,000 likes" on a book review are not the same signal. So the very first architectural decision — before any ranking logic existed — was building a unification layer that maps every content type into a shared shape (type, author, title, cover, category, engagement counters, timestamp) before any scoring happens. Everything downstream depends on that layer being consistent. Generation 1: a weighted ranker living inside a single SQL query The first real version of the algorithm — internally we called it the hybrid model — had a modest goal: get away from a purely chronological feed without building anything resembl

Pruebas una estrategia, o un modelo, sobre datos históricos. El backtest da un número bonito. Y luego, en real, no aparece. Casi siempre es una de estas dos ilusiones — y las dos se descartan con muy poco código. Empaqueté las dos correcciones como librería: honest-eval , Python puro, sin dependencias. Salieron de un bot de trading, pero el rigor no tiene nada de específico al trading. Ilusión 1: el modelo vio el futuro Partir los datos con el clásico train_test_split aleatorio es correcto para datos independientes. En una serie temporal es un desastre silencioso: mete muestras de mañana en el conjunto de entrenamiento, y el modelo "predice" en el test cosas que en producción todavía no habrían pasado. La métrica sale inflada, y confías en un edge que no existe. El test honesto es siempre el futuro : el tramo más reciente en el tiempo. from honest_eval import temporal_split train_idx , test_idx = temporal_split ( timestamps , test_frac = 0.20 , embargo = 24 ) X_tr , X_te = X [ train_idx ], X [ test_idx ] Devuelve índices, así lo aplicas a numpy, pandas o listas por igual. El embargo cierra una fuga más sutil: si tu etiqueta mira h pasos adelante, una muestra de entrenamiento a menos de h del corte ya conoce parte del resultado del test. embargo=h descarta ese borde. La métrica baja — pero por fin es la real out-of-sample . Ilusión 2: la variante ganó por suerte Tienes varias variantes y quieres la mejor. Eliges la de mayor media. Error: con pocas muestras, eso premia la varianza, no la ventaja . La variante más ruidosa suele quedar arriba por azar. Dos correcciones, ambas dentro de select_best_variant : Aparear. Mide variante y baseline sobre el mismo ensayo y trabaja con δ = variante − baseline . La varianza común del ensayo se cancela en la resta, y te quedas con la señal. Exigir cota inferior de confianza > 0. Gradúa una variante solo si media − z·SE > 0 : "incluso siendo pesimista dentro del margen de confianza, sigue por encima del baseline". from honest_eval i

The Quest Begins (The "Why") Honestly, I still remember the first time I tried to build an autocomplete widget for a side‑project. I had a list of 200 k product names, a simple filter that ran on every keystroke, and the UI felt like wading through molasses. Each keypress triggered a full scan of the list, and with a few users typing at once the browser would start to lag. I was stuck in a loop that felt like the infamous “boss fight” where you keep hitting the same pattern over and over, hoping for a different outcome. I kept asking myself: There has to be a smarter way. Why am I re‑checking the same prefixes again and again? If ten users type “tea”, why do I walk through the whole dictionary ten separate times? That question turned into a mini‑quest, and the treasure at the end was the trie data structure. The Revelation (The Insight) Look, the magic of a trie isn’t that it’s some exotic tree; it’s that it stores words by their shared prefixes . Imagine you have the words “cat”, “car”, “cart”, and “dog”. In a trie you’d have a root node, then a c branch that splits into a → t (for “cat”) and a → r → t (for “cart”), while “dog” lives on its own d → o → g path. Every common prefix is stored once , and you can walk down the tree following the characters of a query to land exactly at the node that represents all words with that prefix. Why does this give us O(L + K) time for autocomplete, where L is the length of the prefix and K is the number of results? Walking the trie follows the prefix character‑by‑character → O(L). From that node we just need to collect all words in its subtree. If we keep a list of words at each node (or run a DFS), we touch each result once → O(K). No extra work for words that don’t share the prefix. Contrast that with the naive filter approach: O(N × L) where N is the total dictionary size. For a large N, the trie is a game‑changer—it’s like switching from swinging a blunt sword to wielding a lightsaber that cuts through the prefix forest in

If you've ever wondered whether that wild Pokemon you just caught has competitive potential, you've probably heard the term IVs (Individual Values) thrown around. IVs are the hidden genetics of every Pokemon — the 0–31 numbers baked into your Pokemon at birth that determine how strong it can ultimately become. But here's the thing: the game never tells you what your IVs are. You have to reverse-engineer them. In this post, I'll walk you through exactly how IV calculators work under the hood — from the official stat formula, to the nature modifier trick, to why you often get a range instead of a single number. Live Tool: Try the calculator at randompokemongenerator.me/iv-calculator — free, no sign-up required, supports Gen III through Gen IX. What Are IVs, Exactly? Individual Values are six hidden integers between 0 and 31 , one for each stat (HP, Attack, Defense, Sp. Atk, Sp. Def, Speed). They represent the genetic potential of a Pokemon and are permanently set when the Pokemon is encountered or hatched — they can never be changed by leveling up or any in-game action. A stat with 31 IVs reaches its maximum possible value at level 100. A stat with 0 IVs starts at its theoretical minimum. In competitive play, players typically hunt for Pokemon with at least 3–4 perfect (31) IVs , with some strategies deliberately using 0 IVs in Defense or Speed for tactical advantages. The IV system as we know it today started in Generation III (Ruby/Sapphire/Emerald). Gen I–II used a predecessor called DVs (Determinant Values) , which only covered four stats and worked differently — so if you're playing on Virtual Console or Gen I/II, this calculator won't apply. The Stat Formula (Gen III+) The foundation of everything is the official stat calculation formula introduced in Generation III and still used today: For HP: HP = floor(((2 × BaseStat + IV + floor(EV / 4)) × Level) / 100) + Level + 10 For all other stats: Stat = floor((floor(((2 × BaseStat + IV + floor(EV / 4)) × Level) / 100

Si automatizas un exchange con ccxt , tarde o temprano lo verás en los logs: rachas cortas de 403 Forbidden que pegan a fetch_balance , a los OHLCV o al saldo de earn, y que desaparecen solas a los pocos minutos. No es que tu API key esté mal. Es el WAF (Cloudflare) que muchos exchanges ponen delante de su REST, challengueando a algo que "parece un bot". Y tu bot es un bot — pero uno legítimo , operando tu propia cuenta contra la API oficial. El problema no es de permisos, es de reputación de cliente HTTP. Esto va de reducir los falsos positivos del WAF, no de evadir ningún control de acceso. Dos capas que lo mitigan Saqué este patrón de un bot propio sobre OKX, tras varias rachas de 403, y lo publiqué como librería: ccxt-resilience (Apache-2.0). 1. Que el WAF challengue menos: harden Un cliente ccxt por defecto se anuncia como lo que es. Ajustar un User-Agent de navegador, la cabecera Accept-Language y un timeout holgado hace que Cloudflare lo desafíe con menos frecuencia: import ccxt from ccxt_resilience import harden exchange = harden ( ccxt . okx ({ " apiKey " : ..., " secret " : ..., " password " : ..., })) harden toca un cliente ya construido , devuelve el mismo objeto (encadenable) y nunca rompe su construcción: si algo falla al fijar los atributos, los deja como estaban. 2. Reintentar solo lo que se debe: with_retry La tentación es envolver todo en un try/except que reintente. Es una trampa: reintentar un error de credenciales o de fondos solo gasta tiempo, termina igual de mal, y esconde bugs de lógica detrás de esperas. La clave es reintentar únicamente lo transitorio —403/Cloudflare, 429, timeouts— con backoff exponencial y jitter, y re-lanzar los errores reales en el acto: from ccxt_resilience import with_retry balance = with_retry ( exchange . fetch_balance ) ohlcv = with_retry ( exchange . fetch_ohlcv , " BTC/USDT " , timeframe = " 1m " , attempts = 4 , base = 1.0 , max_s = 8.0 ) Un error de autenticación se re-lanza inmediatamente, sin reintentar. Y s

Casi todo bot de trading tiene una línea que decide cuánto comprar . Suele parecer trivial: si arriesgo el 1% de mi saldo y mi stop está a 1000 dólares de distancia, la cantidad sale de una división. El cálculo es de primaria. Lo que no es de primaria es hacer que ese número quepa en las restricciones del exchange . Ahí es donde se pierde dinero, y de formas que no aparecen en los logs. El patrón que multiplica tu riesgo Esto está en incontables bots, y estuvo en uno mío: cantidad = max ( 1 , int ( cantidad_teorica / contract_size )) La intención es defensiva: "que nunca salga cero". El efecto es el contrario. Si la cantidad teórica sale 0.1 contratos, int() la trunca a 0 , y entonces max(1, ...) la fuerza a uno . Acabas de abrir una posición diez veces más grande que la que autorizaste. Con números concretos: saldo de 500 USD, riesgo del 1% (5 USD), entrada en 50 000, stop en 45 000, contratos de 0.01. El riesgo real de ese contrato único es de 50 USD — diez veces el presupuesto. Y ocurre en silencio: la orden se acepta, el bot sigue, no hay excepción que capturar. Lo peor es que no es un caso raro. Pasa siempre que el saldo es pequeño o el stop es ancho, es decir, exactamente cuando menos margen tienes para equivocarte. Los otros dos que cuestan dinero Ignorar el nocional mínimo. El exchange rechaza la orden por valor mínimo, el bot lo registra como error de red, y nadie se entera de que esa señal nunca se operó. El backtest la contó; la cuenta no. No reservar para comisiones. Con un stop ajustado, las comisiones de ida y vuelta pueden ser la mitad del riesgo real . Si dimensionas contra la distancia al stop y nada más, arriesgas sistemáticamente más de lo que crees. Cómo lo resolví Saqué el cálculo del bot y lo publiqué como librería: position-sizing (Apache-2.0, sin dependencias). from decimal import Decimal from position_sizing import MarketSpec , size_for_risk spec = MarketSpec ( amount_step = Decimal ( " 0.001 " ), min_amount = Decimal ( " 0.001 " ), min_noti

Some creators fear the EU AI Act’s regulatory chaos will upend their lucrative businesses. Others are owning it by incorporating AI transparency into their creative process.

An algorithmic trading platform doesn't operate in isolation it responds to the changing conditions of the financial markets. One of the biggest factors affecting automated trading performance is the market session. Liquidity, volatility, trading volume, and price movements can vary significantly throughout the trading day, influencing how an algorithmic trading platform executes trades. Understanding how different market sessions impact automated trading can help traders choose the right strategies, manage risk more effectively, and improve overall trading performance. What Are Market Sessions? A market session refers to a specific period during which a stock exchange is open for trading. In India, the National Stock Exchange (NSE) and Bombay Stock Exchange (BSE) follow a structured trading schedule that includes the pre-open session, regular trading hours, and post-closing session. Each session has unique market characteristics, making it important for traders to understand how their automated strategies may behave during these periods. Why Market Sessions Matter in Algorithmic Trading An algorithmic trading platform follows predefined rules, but the market environment changes throughout the day. A strategy that performs well during high-volume periods may struggle when trading activity is low. Market sessions influence several key factors, including: Trading volume Market liquidity Price volatility Bid-ask spreads Order execution quality Recognizing these differences allows traders to build strategies that are better suited to specific market conditions. Pre-Open Session The pre-open session is used to determine the opening price of securities before regular trading begins. During this period: Orders are collected but not executed immediately. Prices may fluctuate as the market discovers the opening level. Liquidity can be limited. Large overnight news events may influence price movements. Most intraday automated strategies are designed to become active only afte

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. Humanoid robots usually elicit more cringe than awe: They stumble, kick children, and despite advances are still worse at using their hands than my toddler. It’s a nascent industry, and such robots…

Every esports team captain has done this by hand at least once: open Discord, scroll through a dozen "I can play Thursday after 8" messages, cross-reference them against who plays Tank versus DPS, remember that one of your DPS is actually a sub, and try to assemble a starting five that can actually scrim tonight. It takes fifteen minutes, you get it slightly wrong, and you do it again the next day. I build Supatimer , a free Discord bot for competitive gaming teams, and "generate the lineup for me" was the single most requested feature. This post is about how the lineup optimizer actually works, why it is genuinely AI (and not in the marketing sense), and where a large language model fits in versus where it absolutely does not. "AI" is doing a lot of work in this industry Half the Discord bots on the market slapped "AI" on their landing page the week ChatGPT launched. Usually it means there is a chatbot command somewhere that proxies to an LLM. That is fine, but it is not what your team needs when it is 7:45pm and you have a scrim at 8. There are two honest definitions of AI worth separating: Search and optimization - the classical branch. Constraint satisfaction, combinatorial optimization, planning. This is the part of AI that solves "given these rules and these resources, find the best valid arrangement." Machine learning / LLMs - the statistical branch. Pattern recognition, generation, extraction from unstructured text. The lineup problem is squarely a problem for the first kind. So that is what I built first. The lineup problem, stated precisely Strip away the gaming context and a lineup is a constrained assignment problem: You have N players , each with a set of roles they can fill (Tank, DPS, Support, IGL, and so on). Each player has an availability signal for a given time block (available, maybe, unavailable). Each player has a roster status (starter, substitute, trial). The game defines a required composition : Overwatch 2 wants 1 Tank, 2 DPS, 2 Support. Va

Viral tales of good triumphing over evil are racking up millions of views. They’re almost entirely AI-generated clickbait.

Three approaches to the issue of quantum results that can't be verified classically.

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. Reading OpenAI’s account last week of how some of its models broke their containment and hacked into the computer systems of Hugging Face, another AI company, was the first time I got…

Ink & Switch published bijou64, a variable-length integer encoding where every number has exactly one byte representation, closing the canonicality bug class behind attacks on PKCS#1, JWT libraries, and Bitcoin. The design also decodes two to ten times faster than LEB128. Community ports to Elixir, Go, Perl, and Java followed, while HN commenters debated SIMD performance and residual range checks. By Steef-Jan Wiggers

Once a quirky bastion of amateur vulva jewelry and pet portraits, Etsy is now deluged with mass-produced goods and AI knockoffs. Some customers don’t seem to mind.

If you have written any optimization code, you have met linear programming even if nobody called it that. "Maximize output without blowing the resource budget" is an LP problem, and the classic algorithm that solves it is the simplex method. It is worth understanding not because you will hand-code it (you'll usually call a solver), but because knowing how it moves makes you far better at modeling problems for it. Here is the algorithm stripped down to its logic. The problem shape Every LP problem has three parts: an objective function to maximize or minimize, e.g. Z = 5x1 + 4x2 a set of linear constraints, e.g. 6x1 + 4x2 <= 24, x1 + 2x2 <= 6 non-negativity: all variables >= 0 Geometrically, the constraints carve out a feasible region (a polytope). The optimum always sits at a corner of that region. The simplex method is just a smart way of hopping from corner to corner, uphill, until there is no higher corner to move to. The algorithm as pseudocode build initial tableau (add a slack variable per <= constraint) loop: compute Cj - Zj for each column if all (Cj - Zj) <= 0: break # optimal reached pivot_col = column with most positive Cj - Zj # entering variable ratios = RHS / pivot_col entries (only positive entries) pivot_row = row with smallest non-negative ratio # leaving variable pivot(pivot_row, pivot_col) # elementary row operations return solution from final tableau That's it. Four moves per iteration: score the columns, pick the entering variable, run the ratio test for the leaving variable, pivot. Repeat until the optimality condition holds. A quick worked run Take Maximize Z = 5x1 + 4x2 subject to 6x1 + 4x2 <= 24 and x1 + 2x2 <= 6. Add slack variables s1, s2, build the tableau, and iterate. The optimum lands at x1 = 3, x2 = 1.5, Z = 21. Two pivots and you're done. Simple on paper until the numbers get ugly. Where humans (and debugging) actually break The algorithm is clean. The arithmetic is not. A single wrong entry in one pivot silently corrupts every table

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. Over the weekend, several current and former advisors to President Donald Trump on AI publicly lobbed insults at the country’s leading AI companies. David Sacks, the president’s AI and crypto “czar” until…

Intuition Manacher's Algorithm leverages the symmetry of palindromes to avoid redundant comparisons. Instead of treating odd- and even-length palindromes separately, the input string is transformed by inserting a special character (#) between every character and adding sentinel characters (^ and $) at both ends. This allows every palindrome to be treated as an odd-length palindrome. While traversing the transformed string, the algorithm maintains the center and right boundary of the rightmost palindrome found so far. For each position, it uses the palindrome information from its mirror position (with respect to the current center) to initialize the palindrome radius, significantly reducing unnecessary expansions. Only when the palindrome reaches beyond the current right boundary is additional expansion performed. This optimization ensures that every character is expanded at most a constant number of times, resulting in linear time complexity. Approach Handle the edge case by returning an empty string if the input string is empty. Transform the input string by inserting # between every character and adding sentinel characters (^ and $) at both ends to treat odd- and even-length palindromes uniformly. Create a palindrome radius array p, where p[i] stores the radius of the palindrome centered at index i in the transformed string. Initialize the variables center and right to represent the center and right boundary of the current rightmost palindrome. Initialize max_len and center_index to keep track of the longest palindrome found during traversal. Traverse the transformed string from left to right, ignoring the sentinel characters. Compute the mirror index of the current position using the current palindrome's center. If the current index lies within the current right boundary, initialize its palindrome radius using the previously computed mirror information. Expand around the current center while the characters on both sides are equal, increasing the palindrome radius

Cartography is all about taking the real world and turning it into a picture that people can understand. It’s the process of deciding: what places to show, what details to keep or remove, what colors and symbols to use, how to draw the round Earth on a flat screen or paper Cartography mixes geography (knowing where things are), design (making the map clear and beautiful), and math (flattening the Earth using projections). Every map you see—Google Maps, airport maps, weather maps, D3.js visualizations—is a result of cartography. Line simplification alogorithms are tools used in cartography to reduce the number of points in a geographic shape while keeping the shape recognizable. 🌍 Why do we need line simplification? Real geographic shapes—coastlines, borders, rivers, airport boundaries—are extremely detailed. If you zoom in enough, you can always find more bumps, curves, and tiny wiggles. This is what Lewis Fry Richardson discovered: The more precisely you measure a coastline, the longer it becomes.Because coastlines have infinite detail.But your computer screen does not have infinite detail. It has pixels. If you try to draw a super-detailed coastline - the file becomes huge > the map loads slowly > D3.js rendering becomes slow > zooming becomes laggy > the map looks messy when zoomed out. This is why we need line simplification algorithms. 🎯 What do line simplification algorithms do? They remove unnecessary points from a shape while keeping the overall form. Think of it like: drawing a coastline with fewer squiggles. smoothing a jagged boundary reducing a 10,000‑point shape to 1,000 points. making the map faster and cleaner. The goal is: Keep the important shape, remove the tiny details. 🧩 Why this matters for zoomable maps Zoomable maps (like D3 zoom or Leaflet zoom) need multiple resolutions: When zoomed out → simple shapes When zoomed in → detailed shapes If you use only high‑resolution data: the map becomes slow, too many points are drawn, the user sees clutter

The Quest Begins (The "Why") I still remember the first time I stared at a LeetCode problem that asked me to count the number of islands in a grid. My initial instinct? Run a BFS/DFS from every unvisited land cell, mark everything reachable, and repeat. It worked, but each query felt like I was re‑exploring the same territory over and over again—like walking the same hallway in a dungeon every time I wanted to open a new door. Then a friend tossed me another problem: “Given a list of friendships, tell me if two people are in the same social circle.” Again, the naive solution was to rebuild the whole graph for every query. I felt like I was stuck in a grind‑fest, repeating the same low‑level work while the real challenge—understanding the structure of the connections—remain. That frustration sparked a question: Is there a way to remember what we’ve already discovered about connectivity, so future queries are instant? The answer, as many of you have guessed, lives in a humble but mighty data structure called Union‑Find (also known as Disjoint Set Union, DSU). The Revelation (The Insight) At its core, Union‑Find is about two simple ideas : Each element starts in its own set – think of every person as a lone adventurer. When we learn that two elements belong together, we merge their sets – we call that a union . The magic isn’t just in merging; it’s in how we find the representative (or “root”) of a set later on. If we naïvely walked up a chain of parents every time, we could end up with O(n) per find—still a grind. Two optimizations turn this into near‑constant time: Union by rank (or size) – always attach the smaller tree under the root of the larger one. This keeps the overall tree shallow, guaranteeing that the height never exceeds log n. Path compression – during a find operation, we make every node we pass point directly to the root. It’s like handing every traveler a map that instantly shows the shortest route to the campfire, so next time they don’t need to trek