Why do I get the overwhelming feeling that the author is not a technical person and they had a LLM write this based on some handwavey ideas? There's virtually no _there_ there.
"...demonstrates its capabilities through worked examples" - The hell it does, your "examples" are three lines long. If you're going to compare it with LLMs, then have it do something LLM-ish. Or hell, the MNIST number recognition task would be better than the "hey look i modeled a flip-flop in my funny language" example.
Am I being harsh? Yes, I am. The author is claiming that they have a system that can automatically generate code for "quantum" and "spintronic" computers, yet offers zero proof of that.
It's ok to be harsh — I was vague, and I know it. Here's why: I remember the story about DOS. Tim Paterson built it, showed too much, and someone else built an empire on it for $50K. I have working constraint rules that produce real circuit behaviors. The paper shows what comes out, not how it works, and that's deliberate. The patent is provisional. I'm not going to hand over implementation details on a forum so someone with more resources can run with it. You'd do the same thing.
Bricken's boundary logic is a solid reference point. Both approaches throw out the standard computational primitives and let behavior come from structure instead of instructions.
The difference is what you're constraining. Bricken works with containment and distinction. UCE works with conserved quantities — closer to physics than logic. You define constraints over those quantities, and computational behaviors like memory, oscillation, and logic gating fall out of satisfying them simultaneously.
The other big difference is the output. UCE doesn't produce a proof or a reduction — it produces a state-transition graph that compiles directly to hardware. Same rules, different substrates. That's what the Embodiment Mapper layer does.
The behaviors that emerge — hysteresis, oscillation, bistable memory — are the same computational primitives you see in biological neural circuits, but they come from constraint satisfaction over conserved quantities instead of simulating neurons. The architecture doesn't model neurons at all. It produces the same outputs through a different mechanism. Whether that still counts as "neuromorphic" is debatable — I use the term because the output behaviors map directly to the same hardware substrates (Loihi, SpiNNaker, etc).
Carver Mead's "Analog VLSI and Neural Systems" for where neuromorphic computing started. Intel's Loihi papers (Mike Davies et al.) for where it is now. Our paper takes a different path — constraints instead of neurons.
Why do I get the overwhelming feeling that the author is not a technical person and they had a LLM write this based on some handwavey ideas? There's virtually no _there_ there.
"...demonstrates its capabilities through worked examples" - The hell it does, your "examples" are three lines long. If you're going to compare it with LLMs, then have it do something LLM-ish. Or hell, the MNIST number recognition task would be better than the "hey look i modeled a flip-flop in my funny language" example.
Am I being harsh? Yes, I am. The author is claiming that they have a system that can automatically generate code for "quantum" and "spintronic" computers, yet offers zero proof of that.
It's ok to be harsh — I was vague, and I know it. Here's why: I remember the story about DOS. Tim Paterson built it, showed too much, and someone else built an empire on it for $50K. I have working constraint rules that produce real circuit behaviors. The paper shows what comes out, not how it works, and that's deliberate. The patent is provisional. I'm not going to hand over implementation details on a forum so someone with more resources can run with it. You'd do the same thing.
This is indeed a content-free "paper".
Interesting. Reminds me of William Bricken’s work on boundary logic.
Bricken's boundary logic is a solid reference point. Both approaches throw out the standard computational primitives and let behavior come from structure instead of instructions.
The difference is what you're constraining. Bricken works with containment and distinction. UCE works with conserved quantities — closer to physics than logic. You define constraints over those quantities, and computational behaviors like memory, oscillation, and logic gating fall out of satisfying them simultaneously.
The other big difference is the output. UCE doesn't produce a proof or a reduction — it produces a state-transition graph that compiles directly to hardware. Same rules, different substrates. That's what the Embodiment Mapper layer does.
this seems like a nice rule compiler, but what makes it neuromorphic?
The behaviors that emerge — hysteresis, oscillation, bistable memory — are the same computational primitives you see in biological neural circuits, but they come from constraint satisfaction over conserved quantities instead of simulating neurons. The architecture doesn't model neurons at all. It produces the same outputs through a different mechanism. Whether that still counts as "neuromorphic" is debatable — I use the term because the output behaviors map directly to the same hardware substrates (Loihi, SpiNNaker, etc).
Can you recommend some good books/papers/articles/videos to better understand Neuromorphic Computing and its Applications?
Carver Mead's "Analog VLSI and Neural Systems" for where neuromorphic computing started. Intel's Loihi papers (Mike Davies et al.) for where it is now. Our paper takes a different path — constraints instead of neurons.
[dead]