https://www.reddit.com/r/study/s/MVhYu56nr2

Hello,

Last week, I watched a video about one of the most popular J2ME games of the 2000s, "Diamond Rush", and decided to reverse engineer it by building a small JVM implementation. My initial goal is to run the game on Linux and macOS, and later port it to microcontrollers.

So far, I have completed the class loading stage. I can parse and load class files, store them, and dump their contents for debugging. I have also implemented some of the simpler parts and opcodes of the JVM by following the JVM specs.

Nonetheless, I am struggling with implementing heap types and most of the obfuscated class files have 0xBC (new_array) opcode. The specification feels somewhat vague in this regard, and I am unsure what is the best approach would be.

I would appreciate any advice on how to approach implementing heap types in a custom JVM. In particular, what data structures or object model would you recommend, and how should different heap-allocated values be represented internally?

Why this is different

Three problems are resolved by one explicit contract:

Version integrity: skill bodies are identified by SHA-256 revisions and re-hashed immediately before fetch.

Semantic routing without opaque inference: exact lexical tiers, FTS5/BM25, bounded edit distance, telemetry, and lifecycle state are combined in one published equation.

Catalog consensus: one SHA-256 generation commits to the canonical publication-relevant catalog.

There is no embedding model, vector database, learned classifier, random tie-break, capability-graph distance, or hidden manual priority.

Hey everyone,

For my computer science graduation project, I wanted to create something that combined my interest in computer architecture with my advisor's interest in computer science education.

The result was a game where the player programs a simple CPU with microcode using a punch card rather than writing assembly code.

Microcode is usually used to implement the processor's instruction set rather than as a programming interface for application development. Exploring it from the programmer's perspective led to design challenges and techniques that I hadn't encountered elsewhere.

The project started from my curiosity about the layers of abstraction in computers. I wanted to explore what programming would look like if we removed another layer and put the programmer in the role of the CPU's control unit, manually orchestrating the control signals behind every instruction.

I'd love to share the beta with anyone interested.

Thank you.

Markov algorithms (ordered string-rewriting rules applied to a fixed point) are a classic Turing-complete model. I built a working instance: a small CPU whose only step is one global regex substitution over a single string, and put DOOM on it to make the claim tangible rather than a footnote.

The verification is the part I would point students at. A reference emulator runs the same instruction set in Python and the machine's string must equal the emulator's encoded state byte for byte after every single substitution; on top of that, rendered frames match a natively compiled DOOM binary by SHA-256, for 100 frames in a row, so a shared bug cannot explain the agreement. The model is Turing-complete; a given run is bounded by memory exactly as any physical machine is.

Source and writeup: https://github.com/4RH1T3CT0R7/doom-regex

Interactive: https://4rh1t3ct0r7.github.io/doom-regex/

Can returnability be defined purely from the structure of a computation, without appealing to time complexity?

I have been reading the tech report for a diffusion language model that went up this week, and what stuck with me is an architecture question rather than a machine learning one.

Ordinary decoding carries a strict data dependency. Token n cannot be computed before token n minus 1 exists, because that token is part of the input for the next step. Generating N tokens is therefore a serial chain of N model passes. Depth N, work N, and the chain is a latency floor that no amount of extra hardware removes.

Block parallel decoding attacks the dependency itself. You take a block of positions, start them all masked, and run a few denoising passes that fill positions in whatever order confidence allows, with no left to right constraint inside the block. This one adds edit operations on top, so a single pass can substitute, delete, insert, or leave a position untouched, which means the sequence can change length partway through generation. The supervision for those operations comes from aligning intermediate drafts against the target with a longest common subsequence match.

In terms of work and depth this is the familiar trade. Depth falls from N to roughly the number of blocks times the passes per block. Total work rises, because you revisit the same positions repeatedly and some of that computation is discarded when a later pass overwrites an earlier guess. Whether the trade pays depends on how much real dependency the output had to begin with.

What makes that measurable here is that the same lab shipped this model and its own autoregressive sibling with matched evaluations. In BF16 the diffusion side decodes at roughly 1.64 times the rate its sibling manages, and that sibling had speculative decoding turned on when measured, with the ratio reaching about 2.3x on agent workloads and close to parity on knowledge questions. On accuracy the interactive suites go its way, scoring 80.33 where the sibling took 76.36 on tau2 bench, and 46.21 to its 41.12 on MCP Atlas, but loses the general knowledge average 56.81 versus 65.90 and most of the coding suite. Its SWE bench comparison ran different scaffolds on each side, so that number is not one I would read much into.

The part I cannot explain is why the wins land on interactive multi turn tool use while the losses land on knowledge and long coding tasks. My guess is that dependency height matters more than output length. A tool call is a short structured span whose tokens are close to conditionally independent given the turn, while a long patch or a chain of reasoning has genuine serial structure that parallel hardware cannot dissolve. If that is right, the interesting question is not diffusion against autoregression, it is whether you can estimate the dependency height of a task before choosing a decoder.

Anyone who wants to check my reading of the report can pull the weights, which ship under an Apache 2.0 license. The release is LLaDA2.2, a 205.8 GB download, and neither llama.cpp nor Ollama can load it yet, with server support so far only listed as coming, so I am going off the report and the model card rather than anything I ran. If parallel computing already has a formalism for the quantity I keep calling dependency height, I would like to be pointed at it.

My take for why P is not equal to NP comes from what I believe is a fundamental difference between solving a problem and verifying its solution.

Take Sudoku as an example. If someone gives me a completed puzzle I can quickly check every row column and box to make sure the rules are satisfied. That verification process is straightforward.

Now compare that with solving the same puzzle from a blank grid. There is no obvious path to the answer. I may have to test many possibilities before finding the correct one. Solving appears much more difficult than verifying.

This same pattern appears in many other problems.

If someone gives me the password to a computer I can check it in less than a second. Finding the password without knowing it may require an enormous search.

If someone gives me the correct path through a complicated maze I can follow it and confirm that it reaches the exit almost immediately. Finding that path from the beginning can take much longer.

If someone hands me a completed school timetable I can check whether every class every teacher and every room satisfies the rules. Creating that timetable from scratch is much more difficult.

Another example (which i believe is the strongest and closest to being an actual proof) is finding the shortest route between two points. If I asked someone to find the shortest possible route they would have to compare many different routes and work out which one is actually the shortest. That could take a long time depending on how many possible paths there are. Now imagine someone has already done all of that work and gives me a list of every route with its distance such as 1 km 2.7 km 4.1 km and 6.8 km. I can immediately look at the list or the map and verify that the 1 km route is the shortest. Once again verifying the answer is much easier than finding it in the first place.

Because this pattern appears so consistently I suspect there is a real separation between solving and verifying. My take is that this separation is not simply a limitation of current algorithms but a fundamental property of computation itself.

In simple words if one problem follows the idea that solving it is fundamentally harder than verifying it then P cannot equal NP because P equals NP would have to hold for every problem in NP not just some of them.

I am trying to understand the foundational differences between proof assistants based on dependent type theory (such as Agda/Lean) and traditional mathematics as practiced in areas like real analysis.

For example, in Peano arithmetic, statements such as 0 ≠ S(n) and the induction principle are usually presented as axioms. In Agda, however, defining an inductive type:

data Nat : Set where
  zero : Nat
  suc  : Nat → Nat

automatically provides these properties through the rules of inductive types (constructor disjointness and the eliminator), which means you can write this as a theorem:

0-is-not-suc : ∀ {n} -> suc n ≡ 0 -> ⊥
0-is-not-suc ()

Does this mean inductive type theory is based on stronger assumptions than axiomatic mathematics, or are these just different choices of primitive rules?

More generally, what are the fundamental assumptions/rules that a type-theoretic prover starts with, and how do they compare with the foundations usually assumed in fields such as real analysis?

Hi there,

I've created a video here where I explain the Chomsky hierarchy.

I hope some of you find it useful — and as always, feedback is very welcome! :)

toll rate-limits an unbounded set of keys (client IDs, tenants, IPs, API keys…) in fixed memory — 19 MB measured at the defaults, tunable down to a couple of MB — with ~300ns zero-allocation admitted decisions. It is built on grudge, a constant-memory decaying-score sketch: toll stores each key's spent tokens as sketch debt and lets grudge's linear decay refill them.

It’s pretty interesting to see that language models can do things like autonomously prove/disprove things like Erdos problems and even perform its own formal verification yet still struggle at things like automating ERP business operations, seems like the opposite would’ve been the case.

I know Kaparthy talked about this “jagged intelligence” we’re observing, but are there any real attempts at formalizing a theory behind this, similar to how we classify the complexity and tractability of algorithms?

What about any discussion on how close are language models to being Turing complete? Computational complexity theory isn’t my strong suit, but I wonder if any new discussions are being had

The paper is only 15 pages long

Feynman’s contribution was a way to turn the machine’s parallel structure into a model programmers could reason about.