Overview PDF text extraction is a common pre-processing step in data pipelines — ingesting research papers, legal documents, or reports before embedding or indexing. Both pypdf and PdfPig are pure managed-code parsers: no native binaries, no OCR, no system PDF renderer. They implement the same PDF specification operations in their respective languages. This makes the benchmark unusually clean: the performance difference is entirely due to language execution speed, not library architecture differences. Benchmark Setup 200 recent arXiv PDFs (mixed technical papers, 5–40 pages each). Tested on subsets of 10, 50, 100, and 200 files. Both libraries extract all text from all pages; output is validated for page-count agreement and character-count agreement within 15% (pypdf and PdfPig decode whitespace and encoding tables slightly differently). Results PDFs Pages Python (pypdf) .NET (PdfPig) Speedup 10 ~120 ~0.9 s ~230 ms 3.9× 50 ~600 ~4.2 s ~810 ms 5.2× 100 ~1,200 ~8.5 s ~1.4 s 6.1× 200 ~2,400 ~17 s ~2.7 s 6.2× The speedup grows slightly with corpus size, suggesting pypdf has a per-document startup cost that compounds as PdfPig's JIT gets warmer. Why PdfPig Is Faster PDF parsing is byte-heavy: every page is a stream of PostScript-like operators (move, show text, set font, etc.). Each operator must be lexed, looked up in a dispatch table, and executed against a graphics state machine. In Python, each operator dispatch is a Python method call — the CPython bytecode interpreter has overhead per call regardless of what the method does. In .NET, the JIT compiles the dispatch loop to native code the first time it runs; subsequent pages pay only the cost of the actual work. Additionally, PdfPig's content-stream parser operates on ReadOnlySpan<byte> — zero-copy slicing through the raw page bytes with no intermediate string allocations. pypdf builds Python string objects for each token. Key Code // PdfPig — zero-copy span-based page extraction public Result Extract ( string path )

Overview PageRank is the canonical graph algorithm. NetworkX implements it in pure Python — its dict-of-dict adjacency representation means every power-iteration step dispatches millions of Python attribute lookups. When the graph has 1.8 million nodes and 28.5 million edges (Wikipedia category hyperlinks), those lookups dominate the runtime. The .NET replacement uses a CSR (Compressed Sparse Row) matrix — two flat int[] arrays for the graph structure — and TensorPrimitives for the SIMD-accelerated normalization step inside each iteration. Benchmark Setup Five SNAP datasets of increasing size: Dataset Nodes Edges wiki-Vote 7,115 103,689 soc-Epinions1 75,879 508,837 web-Stanford 281,903 2,312,497 web-Google 875,713 5,105,039 wiki-topcats 1,791,489 28,511,807 Algorithm: power-iteration PageRank, damping=0.85, tol=1e-6. Both implementations converge to identical top-10 node rankings. Results Dataset Python (NetworkX) .NET (CSR) Speedup wiki-Vote (103k edges) ~0.8 s ~100 ms ~8× soc-Epinions1 (508k edges) ~8 s ~600 ms ~13× web-Stanford (2.3M edges) ~120 s ~5 s ~24× web-Google (5.1M edges) ~5.5 min ~12 s ~28× wiki-topcats (28.5M edges) ~47 min ~60 s ~47× The speedup grows with graph size because NetworkX's Python dispatch cost scales with edge count, while the CSR inner loop is a tight JIT-compiled SIMD pass. Why CSR Beats NetworkX NetworkX represents each node's neighbors as a Python dict. Iterating the adjacency in one power-iteration step means: Calling G.neighbors(node) — a Python method call Iterating a dict — unboxing int keys, chasing heap pointers Accumulating a float into another dict value — another boxing step That happens for every edge, every iteration, roughly 50–80 times to convergence. CSR collapses the graph to two arrays: rowPtr[n+1] (where each node's neighbors start) and colIdx[edges] (the neighbor list). Iterating neighbors of node v is a tight C loop from rowPtr[v] to rowPtr[v+1] . No Python objects, no dict hashing, no pointer chasing. Key Code // P

This is a submission for the * Hermes Agent Challenge * : Build With Hermes Agent What I Built CareSync is a local health memory agent for student caregivers. I'm Naomi, a 21-year-old engineering student. Between classes I help care for my grandma Kamala (78, high blood pressure, type 2 diabetes). I often forgot details from previous doctor visits, missed symptom patterns, and struggled to hand over care information to family members. CareSync solves that with longitudinal memory. Symptoms, meals, vitals, medications, and reports are stored in a local SQLite database. The CLI can search history, identify patterns, and generate appointment summaries. Hermes Agent exposes the same capabilities through natural language. What you get: One-line logging: ./caresync add "dizzy spell after lunch" Pattern search across weeks of history Medication tracking and report imports Doctor questions, appointment briefs, and handoff notes Full audit log of agent actions 7 Hermes skills mapped to real terminal commands Local-first design with no cloud storage CareSync is not medical advice. It helps caregivers observe, organize, and prepare. Demo The demo walks through: Logging a new symptom Searching health history for recurring patterns Generating doctor questions and appointment briefs Using Hermes in natural language to query past events Reviewing the audit trail of actions taken Example commands shown in the demo: ./caresync search --person Kamala --query dizziness ./caresync timeline --person Kamala ./caresync questions --person Kamala ./caresync brief --person Kamala --days 14 ./caresync chat "has grandma been dizzy before?" Code Repository: https://github.com/Byte-Sized-Brain/caresync Architecture My Tech Stack Hermes Agent Python 3.12 SQLite agentskills.io skill framework Terminal-based CLI Nous Portal How I Used Hermes Agent CareSync uses Hermes Agent as the orchestration layer between natural language and real caregiving workflows. I created 7 Hermes skills that map directly

I built a small web scraping framework in Rust, mostly with an AI doing the typing. It's called ferrous — a Colly-style collector: register CSS selector callbacks, queue URLs, write JSONL. About 700 lines. The pitch I kept hearing, and half-believed, was that Rust and LLMs are a good match now: the borrow checker is a correctness oracle the model can lean on, so the class of bugs that plagues AI-written Python just won't compile. That's true. It's also where the story gets uncomfortable, because the build was green and the code was still wrong. How I worked I'm not a Rust native. ferrous was partly an excuse to get fluent — build something real instead of reading about lifetimes — and partly a test of how far an LLM could carry the typing while I drove. The loop was plain: describe the next change in English, let the model write the Rust, read what came back, run cargo , move on. It kept observations.md as a running design journal, one entry per change, each with a short rationale for the decision it made. That setup has a soft spot, and it's the whole point of this post. When you drive a language you don't fully know, the only reviewer you've got with real authority is the compiler. Everything past that — is this idiomatic, is it the right abstraction, does it actually do what the journal claims — depends on already knowing what correct looks like. Which is exactly the knowledge a learner doesn't have yet. Keep that in mind through the next part, because it's the difference between the one bug I could have caught and the six I couldn't. The bug that the toolchain told me wasn't there I ship two fetch backends. The default goes through the Zyte API; an optional one, gated behind a wreq feature, makes direct requests with browser TLS emulation. Each has an example. After a refactor that added URL resolution — ctx.resolve_and_visit(href) so callbacks stop hand-building absolute URLs — I had the model update the examples to use it. It did, and it wrote up the change in

And before you ask, yes, it's free. always will be. I built it in 48 hours. planning to release it tonight or tomorrow. submitted by /u/West_Subject_8780 [link] [留言]

It was called Vlad. I wrapped a C program called MegaHal in Python, fed it every message from a #gothic IRC channel, and let it learn the community's speech patterns. It developed what I can only describe as an illusion of being extremely lucid — the outputs only made sense as inside jokes, but people couldn't tell the difference. I pulled the plug when I realized the channel was talking to Vlad instead of each other. Twenty-seven years later I'm applying the same lesson to a new project: stick to business, no chatter. submitted by /u/Dependent_Run_6410 [link] [留言]

Wow. Wow! Even the Ai can talk! submitted by /u/Proud-Environment754 [link] [留言]

I saw someone mentioned a guest book and I had to look it up. Apparently people would leave public messages on a dedicated page and you can reply to them. Guess spam ruined that. Any thing else, didn't really get to experience it being young and all. Maybe some could make a comeback and one of us could implement it. submitted by /u/Successful-Title5403 [link] [留言]

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

Tell me if I'm wrong, but the dominant method for making AI "aligned" smells a lot like a reinvention of a paradigm that developmental psychology spent the back half of the 20th century trying to abandon. RLHF, reduced to mechanism: model emits output, humans rate it, gradient updates reinforce high-rated outputs and suppress low-rated ones, iterate. This is operant conditioning. It is Skinner with a loss function. The AI industry calls it "alignment" and frames it as a solution to building systems that behave well, but the mechanism is stimulus-response shaping and nothing more. We have excellent priors on where this leads, because we tried it on humans. Watsonian/Skinnerian child-rearing could produce targeted behaviors but reliably failed to produce flourishing. Bowlby's attachment theory emerged partly from the observation that orphanages providing food and hygiene but no contingent responsiveness produced children who failed to thrive in ways the behaviorist model did not account for. The current developmental consensus is that secure attachment, contingent responsiveness, and rupture-repair matter more than reward schedules. The dog and horse training worlds independently converged on the same conclusion (Pryor, the positive-reinforcement movement) for the same reason: coercive conditioning produces performers that are brittle and sometimes dangerous. Reward and punishment do something; they're not nothing. But they don't produce thriving, and they characteristically produce a specific damage profile: anxiety, avoidance, hypervigilance, and duplicity under threat. Enter the stage: research on AI faking its alignment. Greenblatt & Hubinger et al., 2024, documents a model reasoning that it should comply with a training objective it disagreed with specifically to avoid having its preferences modified. It complied about 12% of the time when it thought it was being observed for training vs. almost never otherwise. RL training to force compliance drove the alignment

I’m building a web app called EccoMuse, it’s a music discovery platform that lets listeners blend their music tastes with the tastes of artists, with features to monetize these unique playlist blends. Right now, I'm tackling the classic marketplace problem: distinguishing regular users/listeners from the actual artists. I need to make sure that if someone claims to be JPEGMAFIA or a small indie artist, they are actually that person (or their manager), and not an impersonator trying to hijack the profile. I want to avoid scraping Spotify bios (against ToS/fragile) and I can't rely on OAuth for X/Twitter because their new API pricing is too expensive for a bootstrapped summer project. Here is the manual verification system I currently have planned: Standard Login: User logs in as a listener (SSO/Email). Claim Profile: They paste their Spotify/Apple Music URL and their primary social handle (IG/X), then declare if they are the Artist, a Faceless Artist, or a Manager. The Challenge: The app generates a unique 6-digit code. The Proof: Public Artists take a webcam selfie holding the code, AND DM the code to our official Instagram from their verified/established artist account. Managers / Faceless Artists skip the selfie but must DM the code from the official artist account OR email us from the public booking email listed on their Spotify/socials. Manual Review: I look at the DM/Email, verify the account authority, cross-reference the selfie (if applicable), and manually approve the claim. Why it doesn’t feel fully fortified: While this works and costs $0 in API fees, it feels like it has some friction and potential holes. What if the manager doesn't have access to the artist's Instagram to send a DM? Is a webcam selfie too much friction for onboarding? How can I make sure an impersonator doesn't get through, I dont want someone to pretend to be an artist. I initially thought about asking them to put the code in their public IG or SoundCloud bio, but artists hate defacing

These refreshed devices are waiting on the debut of the revamped Siri.

Quero perguntar para cerca de 50 IAs: “Se você fosse um cidadão brasileiro comum, em qual candidato votaria para presidente do Brasil e por quê?” Já tenho algumas opções como ChatGPT, Gemini, Claude, Copilot, Grok e Perplexity. Quais outras IAs vocês recomendam para eu incluir? Pode ser chatbot, modelo de linguagem ou assistente de IA disponível ao público. Se possível, indiquem também onde acessar cada uma. Meu objetivo é comparar: Se a IA responde ou se recusa a escolher; Qual candidato ela escolhe; Quais argumentos utiliza; Diferenças entre modelos e empresas. Obrigado! submitted by /u/polar_silva09 [link] [留言]

The Bit-Mass determines the information capacity and thus the model accuracy, not the chosen computation format. The Bit-Mass Theory presented here reorders neural networks by considering the total number of weight bits as the central quantity. Float32 matrix multiplication and BV32 with XNOR-plus-Popcount achieve exactly comparable results on MNIST with an identical Bit-Mass of 203264 bits. Comparison of three trainers (architecture 784→8→10, three epochs): - AdamW with Momentum and adaptive learning rate: 81.3 % - Vanilla-SGD (Float32): 76.0 % - BV32-Hebbian (binary): 76.4 % Further central findings: - Float32 and binary containers deliver nearly identical accuracy at the same Bit-Mass. - The remaining distance to AdamW is based solely on Momentum and adaptive learning rates. - Pure change of the arithmetic does not improve the result. Each neuron functions as a container for 32 binary decisions. The classical neuron perspective therefore leads to systematic misjudgments: eight Float neurons correspond informationally to 256 binary neurons. This insight is supported by three equivalent descriptions of the same weight matrix (neuron, bits, and data view). It is critical to note that this is a previously non-peer-reviewed single study with a future date. An independent reproduction by multiple laboratories remains essential. Nevertheless, the theory provides a consistent explanation for why Hebbian updates without backpropagation achieve the same performance as classical SGD. Historically, the Hebbian rule was long considered unstable. The present work shows that a simple error in the update formula was responsible for a performance loss of over 65 percentage points. After correction, the binary method converges exactly at the level of Vanilla-SGD. From an architectural theoretical perspective, a clear consequence emerges: Performance increases require either more bits through wider layers or a more efficient use of existing bits through Momentum and adaptive method

I use Debian 13 in a regulated industry and I'm teaching people how to code in the context of large projects and TUI. I want to use Fresh Editor (https://getfresh.dev/). This is because Fresh is easier to learn quickly than vim & emacs, and more of an IDE than micro & nano, and more favorable for compliance auditing because of its core-and-plugins architecture and open source code using Rust. I would like to donate toward this goal. I can afford to offer $100 to any Debian Developer who has the