标签：#learn

Okay Okay, I've used the Rust book online and W3 schools mostly to learn most of what I know. Plus a video or two, but I can't focus on them as of well. Alright, first time putting this to text, but I'll try and explain the concepts, how I myself understand them. From Ch 3 of the Rust book. So in CH 3 it essentially focuses on variables )your x's, y's etc. etc.( and how variables in rust are by def not able to changed, "immutable" by the book. The gist of why is that it guarantees the variable isn't changed when it's not supposed to be or by another function. It also just serves like a safety blanket of sorts, say if you were to have a huge program. You use "let x = 5" you'll know that x = 5 EVERYWHERE. It won't change because the program won't run, you won't even get past the compiler if you try and change the value without saying it can change. This helps in stopping bugs from cropping up, specially since it's how malactors get in. helps debugging by knowing what can and can't flip a bit. Plus if you're building robust code, less stuff changing is better, cuz less stuff fails.. Like a car. fn main () { let x = 5 ; x = 20294 ; // you can't change this, it'll show as an error since you "x" isn't "mut" mutable, or changeable. } simple, right? Roast me if wrong. 08.10.26 -Tyr

Hello, I wanted to share the work my colleague and I have been doing, which has just been published in Software X journal . We developed a Rust-based implementation of Random Forest. It has bindings for both Python and R . Fru is highly optimized, offering competitive runtime performance and better scalability than popular implementations on these platforms. For Python, Fru outperforms the scikit-learn implementation by several factors, and in some scenarios it can be hundreds of times faster. In R, Fru is typically a few dozen percent faster than the ranger package, though the speedup can reach several times faster depending on the use case. The model also includes a novel implementation of permutation importance, which provides an additional performance boost. Thanks to its layered design, we were able to easily create bindings for both Python and R. In Python, we use Arrow PyCapsule, which allows the model to work seamlessly with any compatible library, including pandas, polars, pyarrow, and many others. paper R package Python package submitted by /u/kpiwonski [link] [留言]

Obviously nobody needs a transformer that's good at multiplication. I wanted to know whether a stock transformer could do exact arithmetic if I chose its weights directly. I implemented the grade-school algorithm as a computation graph and compiled it into an ordinary Phi-3 Hugging Face checkpoint using Torchwright, a compiler I wrote. No training. The three-digit calculator gets all 3,000,000 supported expressions right. I've published checkpoints to Hugging Face that support up to 12 digit x 12 digit multiplication. For fun, I also disabled reasoning and tested six frontier models. Accuracy falls off a cliff as the numbers get longer; at seven digits, five scored 0/500. Mine stays at 100%, although it has the considerable advantage that I put the multiplication algorithm directly into its weights. I ended up building four versions: grade-school, hardware-style, scratchpad, and brute-force memorization. They compute the same function while spending layers, width, generated tokens, and parameters very differently. Write-up: https://ood.dev/posts/calculator/ Repo: https://github.com/physicsrob/torchwright Checkpoint: https://huggingface.co/physicsrob/torchwright-calculator-simple-max-digits-3 submitted by /u/notforrob [link] [留言]

Hi, I would like to file a complaint about an accepted and published CVPR 2026 paper that its main contribution is a dataset but it was never released, and honestly I don’t know who to contact. The dataset was never released prior to the conference, or during the conference or after the conference. I personally feel there was a lack of proper checking that the dataset was gonna be available before the conference since this is a requirement. I’ve tried contacting the authors without any success (which tbh I wouldn’t even need to because it has to be released anyways). The authors even point a GitHub link in the paper but the repo is empty (and it was always empty). submitted by /u/ElPelana [link] [留言]

I spent six months trying to make v2 work. Then I built a small thing on the side that worked better than v2 ever had. The decision that followed wasn't whether to change architectures. It was how fast. Part 22 ended on a pattern I'd been seeing without quite seeing. PropertyCircuit and RelationalCircuit had each landed a capability the brain layer couldn't reach, at a fraction of the parameter count, in seconds of training, with zero impact on anything else in the system. The implications sat in the session notes for a couple of days while I ran the numbers in different ways trying to find a reason they didn't mean what they obviously meant. I couldn't find one. The pattern was real. The reason it was real was structural. A monolith optimized for one thing tends to be worse at every other thing. A small circuit optimized for one thing tends to be better at that one thing than any general-purpose model would be, and the cost of building it is small enough that you can build a lot of them. I sat down at my computer staring at the screen, running the design through my mind. I had been doing the engineering work in a collaboration for months. I held the design vision and the final say on what shipped. The conversation about v3 had to be the two of us together, because nether one of us would have noticed the pattern alone. The conversation took most of a day. The output was a file in the v3 repo called TRUTH.md with ten rules in it. Two-way agreement required for any architectural change. No regex patterns in dispatch unless they used what Origin already understood. Sandbox before shipping. Trace impact before shipping. Honesty floor: Origin only says what it knows. Modularity all the way down. A few others. The rules weren't aspirational. They were the patterns we'd already learned the hard way over fifteen blog posts of failures. We'd just never written them down in one place where they could constrain the next decision. The architecture that came out of the conversat

Today the most important factor in AI is cost. My idea is to split ML models inference (closed ones, proprietary) across server and edge computing on clients, and I would like to hear what do you think about this thing. For example some of model weights/modules would be on client, and some on the server side (where user has no access to them). This could potentially un-load some processing from datacenters, moving part of the cost to the client hardware. Probbably the most important question here will be how to achieve this - and I believe one hypothetical option will be to train like two separate models - client model and server model, and they will communicate through tensors/latent representations across network protocol. Secondly such split of server side and client side model ends, can provide later some beneficial outcomes I hope (because in between "talk" protocol can be maybe kind of standarized one in some future development, but this is only more like brainstorm now). Such split might not only be one-to-one, but one-to-many, many-to-many etc. What do you think about this idea? submitted by /u/komorra [link] [留言]

Say you want to swap out your embedding models, for instance from ADA to Titan. Are these embedding models comparable? How do similarity score ranges compare? Where to put a threshold for minimum match when doing retrieval? Or more from a research point of view how can we relate and fundamentally understand these embedding spaces better? This is what we aim to solve with Synthetic Query Probing, a fancy name for essentially (and intentionally) a very simple approach: embedding spaces are not directly comparable by definition, so compare similarity spaces instead, similarity match scores for pairs of content (synthetic question, chunk for instance) across multiple embedding models. For example, similarity scores of Titan models of different dimensionalities are related, whereas the relation between Titan and Ada scores is non-linear, with different ranges, see figure. https://preview.redd.it/eauhd4hdyiih1.png?width=4767&format=png&auto=webp&s=e424c836c48962928d9505cf747e7cd9fb0b719f See https://arxiv.org/pdf/2608.05857 , Marcin Rozmus and Peter van der Putten. Similarity Spaces across Embedding Models with Synthetic Query Probing. Discovery Science 2026, October 5-9, 2026, Mainz, Germany submitted by /u/pppeer [link] [留言]

From Learning to Teaching: Building Bitcoin Tools in Rust Susan Githaiga Susan Githaiga Susan Githaiga Follow Aug 10 From Learning to Teaching: Building Bitcoin Tools in Rust # rust # bitcoin # opensource # buidl4africa 1 reaction Add Comment 3 min read

We’ve all been there: hunched over a keyboard at 3 AM, neck craned forward like a turtle, debugging a race condition. "Tech neck" isn't just a meme; it’s a productivity killer. As developers, our spine is our most underrated hardware. In this tutorial, we are going to build a Real-Time Spine Posture Monitor . We will leverage real-time human pose estimation and MediaPipe Python libraries to track your posture via your webcam. By the end of this guide, you'll have a system that detects when you're slouching and sends a system notification to keep your ergonomics in check. This project is perfect for those looking into OpenCV computer vision and developer ergonomics solutions. The Architecture 🏗️ The logic is straightforward: we capture video frames, process them through a pre-trained neural network to find body landmarks, and apply some basic geometry to determine if your posture is healthy. graph TD A[Webcam Feed] --> B[OpenCV Frame Processing] B --> C[MediaPipe Pose Landmark Detection] C --> D{Extract Shoulder & Ear Coordinates} D --> E[Calculate Neck Inclination Angle] E --> F{Angle > Threshold?} F -- Yes --> G[Trigger System Notification] F -- No --> H[Continue Monitoring] G --> B H --> B Prerequisites 🛠️ Before we dive into the code, ensure you have the following installed: Python 3.9+ MediaPipe : Google’s framework for cross-platform ML. OpenCV : For video stream handling. PyObjC : (For macOS) to trigger native system alerts. pip install mediapipe opencv-python pyobjc Step 1: Initialize the Pose Engine MediaPipe makes pose estimation incredibly easy. We’ll use the Pose solution, which provides 33 3D landmarks for the human body. import cv2 import mediapipe as mp import math # Initialize MediaPipe Pose mp_pose = mp . solutions . pose pose = mp_pose . Pose ( static_image_mode = False , model_complexity = 1 , enable_segmentation = False , min_detection_confidence = 0.5 ) mp_drawing = mp . solutions . drawing_utils Step 2: Calculating the "Slouch" Angle 📐 To detect

I spent two weeks building a computer vision component to estimate how full a plastic container is from drone imagery. Translucent white containers, whitish chemical product inside, shot obliquely from a drone during field inspections. The headline number looked good: mean absolute error of 0.055 on fill fraction, Pearson correlation of 0.97. Then I audited my own evaluation and found that 38 of my 46 test crops had the same physical container sitting in the training set. The arithmetic was fine. The problem was the sentence I had wrapped around it: I was presenting 0.055 as the error on containers the model had never seen before. What makes this worth writing about is that I had the guardrail in place from day one, and it failed three separate times for three unrelated reasons. Each one is easy to reproduce in any project that trains on frames extracted from video. Why grouping matters here at all A drone flies over a site and captures a burst. In my case, 12 frames over 12 seconds. The same physical container appears in every frame of that burst, from slightly different angles and distances. If you shuffle those crops randomly into train and test, you are asking the model to recognize a container it has already memorized. The metric you get back describes interpolation between frames of one burst. It says nothing about a container the model has never seen. This is the most common failure in applied ML and everyone knows about it. Which is exactly why the next part is worth reading. The guardrail I wrote on day one My dataset module reads the grouping column from config and does not offer a random option at all: split : group_column : skid_id # never random The code path for a random split does not exist. You cannot pass a flag to get one. I wrote it that way on purpose, on the first day, before there was any data to split. I still leaked. Three times. Leak 1: the group column held the wrong ID group_column was set to skid_id , which is what you want. Group by phys

Hi everyone! 👋 I recently developed LoanAI , a real-time credit risk assessment platform that predicts loan default probabilities using machine learning models. Key Features Instant Risk Scoring: Real-time credit risk assessment for loan applicants. Explainable AI: Transparent prediction logic for financial decision-making. Clean UI: Built with Flask, Bootstrap 5, and Python. Live Demo Check out the live web app here: LoanAI Web Application I would love to hear your feedback on the project structure and prediction engine!

I keep seeing the same local LLM sizing mistake: "The model file is smaller than my GPU, so it should fit." That is only the first check. A 24 GB GPU does not give your model a clean 24 GB memory budget. The display stack, runtime, temporary buffers, model weights, and KV cache all compete for the same space. Here is the worksheet I use before I download a model or rent a GPU. 1. Start with the weight floor The simplest weight estimate is: weight_memory_gib = parameters * bits_per_parameter / 8 / 1024^3 For a simple 4-bit estimate: Model size Weight floor 7B 3.3 GiB 13B 6.1 GiB 70B 32.6 GiB These are floors, not promises. Real quantized files can also contain scales, metadata, and layers stored at higher precision. If you know the exact checkpoint size, use that instead of the simple bits-per-parameter estimate. Also use total parameters for a sparse mixture-of-experts model unless your runtime really offloads inactive experts. Active parameters describe compute per token. They do not automatically describe how many weights must be stored. 2. Reduce the physical capacity to a usable budget I normally start with 90 percent usable VRAM for planning: usable_vram = physical_vram * usable_fraction For a 24 GB card: 24 * 0.90 = 21.6 GiB usable The exact reserve depends on the OS, display use, driver, runtime, graph capture, allocator behavior, and other processes. The important part is to stop treating the number on the box as fully available. 3. Add the KV cache The KV cache is where context length and concurrency become expensive. A useful planning formula is: kv_cache_bytes = 2 * layers * kv_heads * head_dimension * context_tokens * concurrent_sequences * bytes_per_kv_value The factor of two stores keys and values. Take a model with: 32 layers 8 KV heads 128 dimensions per head 8,192 cached tokens 1 concurrent sequence 16-bit KV values, which use 2 bytes The KV cache is about 1 GiB. Raise the context to 32,768 tokens and it becomes about 4 GiB. Keep that context and ru

Originally published on tamiz.pro . The promise of AI-assisted coding is seductive: velocity, reduced boilerplate, and the elimination of context-switching fatigue. Tools like GitHub Copilot, Cursor, and various IDE plugins have transitioned from novelty to necessity in many modern codebases. However, a subtle but dangerous drift is occurring in our development practices. We are witnessing a shift from "writing code" to "reviewing AI output," and in doing so, we are ceding our most valuable asset as engineers: agency. When we stop asking how a system works and start accepting what the machine says it does, we degrade our ability to debug, architect, and innovate. This article argues that maintaining developer agency in the age of automation is not just a philosophical stance, but a critical engineering requirement for building robust, secure, and maintainable systems. The Illusion of Competence The primary threat to developer agency is the illusion of competence. When an AI generates a complex React component, a sophisticated regex, or a multi-join SQL query in seconds, it creates a cognitive shortcut. The human mind, prone to efficiency, often skips the deep verification step because the output "looks right." This is known in psychology as the fluency heuristic—the ease with which information is processed is mistaken for its truthfulness. Consider the following scenario. You are tasked with implementing a rate-limiting middleware for an API endpoint. Instead of reviewing the existing express-rate-limit library or writing a simple in-memory counter, you ask your AI assistant to "create a custom rate limiter using Redis." It provides a snippet using ioredis with a sliding window algorithm. The code compiles. It runs in your local environment. You merge the PR. Three months later, under load, your Redis connection pool exhausts. The AI-generated code did not handle connection errors gracefully, nor did it account for the latency spikes introduced by the network round-

submitted by /u/katxwoods [link] [留言]

submitted by /u/ImaginaryRea1ity [link] [留言]

Reasoning alone cannot predict the chaotic physical world. Without a sensory and motor interface to reality, non-physical AI will not deliver the scientific and technological breakthroughs we expect. submitted by /u/dontkry4me [link] [留言]

Large language models have enormous context windows now. That does not mean they use all of that context reliably. As prompts grow, models can miss details, lose track of relationships, or produce plausible summaries instead of doing the exhaustive work a question requires. The Recursive Language Models (RLM) paper proposes a different interface: keep the large context outside the model, expose it as a variable in a persistent programming environment, and let the model inspect, partition, and recursively query smaller pieces. We rebuilt that method with an unusual constraint: no OPENAI_API_KEY ; Codex CLI as the model backend; gpt-5.4-mini for both the RLM root and every subcall; a direct frontier model only as a separate baseline. The result was encouraging, expensive, and more nuanced than “cheap model equals frontier model.” What an RLM changes A normal model call looks roughly like this: large prompt -> model -> answer An RLM instead gives the root model metadata about the input and a Python REPL containing the real context: question | root model | persistent REPL holding the context |-- inspect and search with code |-- split context into useful chunks |-- call smaller LMs over those chunks |-- validate and aggregate results `-- return the final answer The important detail is that the root model does not need to carry every document, record, tool result, and partial answer in its own context window. Large intermediate values can remain in REPL variables. Subcalls receive focused, locally understandable tasks. That makes RLM less like a bigger prompt and more like an out-of-core data-processing system whose semantic operator happens to be a language model. What we actually tested We used an OOLONG trec_coarse validation example from the protocol described in the RLM work. The input was a 308,367-character context containing 3,182 general-knowledge questions. Each question implicitly belonged to one of six answer types: numeric value entity human being location ab

Does anyone have any idea about the instructions for the camera ready at workshops? The deadline is August 15, but there are no indications and workshop organizers know nothing about that.. Some workshops have enabled the upload of camera ready PDF on openreview, but what about copyright form and latex source files? submitted by /u/rokk07 [link] [留言]

You're Not Comparing Models. You're Comparing Contracts. Two teams publish scores on the same agent benchmark. One lands in the low sixties. The other clears seventy. A procurement team reads the spread and makes a call. What they do not see: both teams may be running the same model. They did not need to change the weights for the gap to appear. The spread can come from scaffold alone. One team wrapped the model in a harness with better retries. Different tool defaults. A planner step the other team had skipped. None of that appears on the leaderboard. The comparison that drove the decision was not between two agents. It was between two contracts. There Is No Benchmark The mistake hiding behind this story is a category error. People talk about agent benchmarks as if they measure a thing called “the model.” They do not. They measure a coupled system. The model is one component. The rest is a stack of protocol decisions that are almost never disclosed and almost always matter. The score is the output of that stack. Change any layer and you change what the number means. Recent research on agent evaluation has named those layers explicitly. There are at least seven. Deployment regime. Observation channel. Harness and scaffold. Metric and action. Configured evaluator. Grader protocol. Audit bundle. Each is a contract. Each is negotiable. And each can silently change the verdict while the headline looks the same. That is what a benchmark actually is. Not a measurement of a model. A measurement of an entire testing contract, of which the model is one slot. There is structural reason the seven layers are the seven layers. They cluster into three corners that show up in almost every published agent-evaluation failure. What the model is rewarded for. How that reward is optimised. And how the test contract differs from production. Once you hold those three corners in view, the seven-layer stack stops feeling like a checklist and starts behaving like the actual shape of what is

Your Tools Got Powerful. Get Boring. Subscribe now The bored trader beats the machine On one side of the trade sits a market-making engine that represents the genuine state of the art: Hawkes processes modelling order arrivals, Kyle’s lambda pricing the impact of each fill, Avellaneda-Stoikov inventory control balancing the book in real time. Years of mathematics, running on hardware that did not exist a decade ago. On the other side is a momentum trader whose entire system is price, volume, and three moving averages. He sits in cash most of the year doing nothing, waiting for a setup he could describe to you in a sentence. His stack is deliberately primitive. His edge is patience and the discipline to follow his own rules when they are boring and to sit out when they are silent. Over a full market cycle, the boring one is more likely to still be standing. This is uncomfortable, because it runs against an intuition almost everyone shares: better tools should let you run better, more sophisticated strategies. More compute, more data, more powerful models, therefore more elaborate approaches and better results. It feels obviously true. It is the logic behind most of what gets built, bought, and bragged about. It is also, across domain after domain, wrong. And the interesting part is the shape of the curve. The gap widens as the tools get stronger Here is the pattern the most successful practitioners keep seeing, whether they are trading, building software, learning, or shipping products. Powerful tools do not pay off when you point them at more complex strategies. They pay off when you point them at simple strategies and execute those faster, more consistently, and with less drift than anyone else. More power applied to a simple strategy compounds. The same power applied to a complex one mostly buys you more ways to be wrong. Sit with the second half of that, because it is the part people miss. A sophisticated strategy is not free. Every additional layer needs to be s