Most AI models today either forget too quickly (catastrophic forgetting) or struggle to generalize across tasks without retraining. But what if we modeled AI memory as a Hamiltonian system, where information evolves over time in a structured, physics-inspired way?
I've been experimenting with a Hamiltonian-based neural memory model (TMemNet) that applies time-evolution constraints to prevent forgetting while adapting to new data. Early results on cross-domain benchmarks (CIFAR → MNIST, SVHN → Fashion-MNIST, etc.) suggest it retains meaningful structure beyond the training task—but is this really the right approach?
Does AI need a physics-inspired memory system to achieve human-like learning?
How do Hamiltonian constraints compare to traditional memory models like ConvLSTMs or Transformers?
What are the biggest theoretical or practical challenges in applying Hamiltonian mechanics to AI?
Would love to hear thoughts from scientific computing & AI researchers! If anyone’s interested, I also wrote up a pre-print summarizing the results here : https://doi.org/10.5281/zenodo.15005401
How could I get endorsed in arXiv to submit a python package paper that help analyzing Thawing Scalar Fields.
arXiv says: "You must get an endorsement from another user to submit an article to category physics.comp-ph (Computational Physics)."
arXiv also provides a link for endorsement, but I do not want to spam people emails with someone who they do not know.
Can anyone with experience help?
We present the **Thawing Field Analyzer (TFA)**, a Python package for reproducible, route-level analysis of canonical thawing scalar-field dark energy. A route is specified by a potential V(φ), its field-space derivative, and frozen initial field data. The package no integrates the homogeneous Klein–Gordon system in a flat FLRW background to obtain the scalar trajectory, equation of state, scalar density fraction, and dimensionless expansion shape E(z).
The central operation is acoustic normalisation. The Hubble constant H₀ is derived self-consistently by matching E(z) to the CMB acoustic angular scale, making the normalisation a consequence of the scalar dynamics. The normalised history H(z) = H₀ · E(z) is then used by every downstream module. A physics-guard layer evaluates canonical non-phantom behaviour, thawing monotonicity, phantom-crossing status, and the scalar density fraction at BBN. A BAO module computes D_H, D_M, and D_V from the route's own drag-epoch horizon r_d and evaluates residuals against the bundled DESI DR2 data vector. An RSD module evolves the linear growth factor inside H(z), computes fσ₈(z), and evaluates residuals against an 18-point compilation. Each run is recorded as a structured, timestamped folder containing the frozen input configuration, expansion and trajectory tables, per-datum residual tables, summary JSON records, and exported plots.
The workflow is demonstrated on eight source-backed routes comprising two Warm Quintessential Inflation markers and six Warm Little Inflaton markers, chosen to exercise the pipeline across different expansion and growth histories. The demonstration reports route-dependent values of H₀, r_d, BAO and RSD χ², growth ratios, and σ₈, together with the corresponding tables and plots generated by the package.
The package is open source and available under the MIT license.
The video explores: • Numerical integration • Taylor series truncation error • Local vs global error • Forward Euler, Backward Euler and Symplectic Euler • Stability and energy drift • Why symplectic methods are favoured in physics engines
A few months ago I started wondering: what happens if you try to build something mind-like without giving it variables like FEAR, BELIEF, GOAL, CURIOSITY or HABIT? Instead, I gave an agent a physical world, a body, limited perception, bounded memory, prediction and actions with physical consequences. Then I started testing what can actually emerge from those mechanisms. So far I’ve seen predictive compression, novel prospective trajectory composition, acquired predictive use of observations, history-dependent behavior, and physical signaling between agents. But the important part is what I can’t claim yet: prospective composition isn’t automatically planning, physical signaling isn’t communication, and acquired observation isn’t curiosity. The project is called Mechanistic Mind, and the first public integration is Tiktaalik 🐟 I just released Public Beta 1 on GitHub: archonlab/mechanistic-mind I’ll probably post some of the individual experiments here, including the ones that failed.
To keep things short, the recent OpenAI paper dump included a result on DFT being fundamentally flawed/ill-defined in certain coulombic configurations.
Considering this, do we have an alternative computational scheme which is both efficient and also does not have the same hypothetical breakdowns that DFT does?
I’m building a modular, GPU-accelerated 3D physics engine from scratch real-time, constraint-based, and built for soft bodies, chaotic systems, and high-performance collisions. In the last 3 months I've built 2 engines on my own and I'd love to do it with some friends (none of mine understand c++ or newtonian mechanics that well) so im looking for new friends. I’m a physics and CS double major starting small with 3 to 5 devs who want to learn, build, and push boundaries together. If simulation is your hobby or you’re just looking for a challenge, this might be your crew. We’re working in C++ with CUDA and OpenGL, meeting weekly, and sharing code on GitHub. It’s not just a flex. it’s a launchpad into simulation, where real innovation (and AI) is heading fast. DM me if you’re curious.
My team and I couldn't connect with any professors or previous publishers who have uploaded to arXiv. We're looking for someone to endorse our submission.
Paper Title: Low Weak Form Loss, Wrong Solution: Evidence from a Coupled Electrochemical Neural Operator
Abstract: We tested whether the weak-form physics loss finds the right answer without any data to guide it. On a nonlinear corrosion problem, it doesn't. The weak-form model does no better than guessing zero, while a matched strong-form model on the same problem gets it right. The gap looked even bigger than it really was, because we first checked accuracy only at the final time, and the weak-form field kept drifting long after the true system had settled. A standard fix aimed at exactly this failure mode didn't close the gap either.
I am pleased to share a project I have been developing: decoint. This is a interval arithmetic library written in Python, designed specifically to strictly adhere to the IEEE 1788.1-2017 standard for interval operations.
The Problem:
Most general-purpose numerical libraries do not enforce strict rounding-mode safety or standard compliance out of the box, which can lead to silent error accumulation in chaotic simulations or global optimization tasks. My objective was to construct an intuitive, pythonic interface that guarantees verifiable numerical boundaries without forcing developers to drop down into low-level C libraries manually.
Technical Highlights
Strict IEEE 1788.1-2017 Compliance: Designed to match the foundational requirements and set-theoretic definitions of the core standard.
Multi-Precision Boundaries: Built directly on top of gmpy2 (with MPFR). This allows the runtime to handle arbitrary, high-precision interval bounds and bypasses the limits of hardware floats.
Rigorously Bounded Arithmetic: Implements standard-compliant containment rules for handling mathematical edge cases, ensuring that operations involving division by zero, unbounded limits, and infinities reliably result in mathematically sound intervals.
The repository includes a basic guide of the operations that the library covers and the recommended way to use the library to its fullest potential in USAGE.md.
I would greatly appreciate any technical feedback from the community regarding the structure of the package, performance considerations with the underlying gmpy2 objects, or any additional interval operations you may require for your research. Thank you!
I've been working on a numerical solver app for a while, mainly because I wanted something that could handle the kinds of mathematical problems I come across without having to switch between several different tools.
The first version focuses on solving algebraic equations and systems, as well as plotting functions and visualizing the results.
The app is free, and I'm gradually expanding it into something more general for numerical computation.
context:- i am a 1st year student majoring in physics. thing is i am interested in computational physics (mainly DFT simulations and ML analysis of data). i want to learn these concepts and get proficient at them, but the thing is, our uni doesnt guve HPC access until the 4th year, so i am settling for a rig of my own. budget isnt an issue, but im confused as to what i wanna buy. should i buy a PC with an NVIDIA GPU (im targetting smth with 8-12 GB VRAM) and a good processor with a hgih core count (i have found one with 16 cores, 32 threads, and it has FP64 at 2.5 TFLOPS) or should i buy a mac? the reason why im so keen on the devuce is bcz i want to learn DFT and ML buy running small-medium scale programs locally before eventually gettung access to HPC via projects where i show competence in programming and thr subject itself. please tell me based on my above reasons, and also tell me the specs of the device i need to buy.
Hey everyone, I’ve been building LaTeX Core for collaborative research reports at my university. It runs on your own server, with real-time editing and PDF compilation.
The part I focused on is the student–supervisor workflow. Supervisors can draft feedback privately, then publish it when they’re ready. Students get highlights in the LaTeX source, and clicking a comment opens the right file and jumps to the relevant section. Team leads handle version restoration rather than sending every request through an admin.
There’s also CSV/Excel import for creating teams and assigning mentors, plus programme-based templates and configurable cover pages, acknowledgements, etc. Basically, less manually setting up the same stuff for every student
An earlier build is running on our university’s staging server now. Still working through some deployment rough edges, so feedback would genuinely help.
I wrote this code to perform the Gaussian elimination to solve Ax=b
import numpy as np
A=np.array([[4,8,12],[3,8,13],[2,9,18]])
b=np.array([4,5,11])
def Gauss_Elimination(A,b):
n = np.shape(A)[0]
for k in range(n):
pivot_element=A[k,k]
# if pivot_element==0: ### I'll deal with this condition later
for j in range(k+1,n):
A[j,:]=A[j,:]-(A[j,k]/pivot_element)*A[k,:]
b[j]=b[j]-(A[j,k]/pivot_element)*b[k]
return A,b # not necessary since it's call by reference
Gauss_Elimination(A,b)
print(A,'\n',b)
A is transformed to an upper triangular form but the values of b rest unchanged, why? I'm asking this question even thought I know it's a silly mistake I can't notice, since A is fine, it must no come from the algorithm!
I know I'm missing the 2nd part of the algorithm where I should go back and find the values of x, but I'm first trying to get the first part correctly!
I built axiomize-quantum-skills-2.0 because I kept making the same mistake in scientific work: picking the first plausible explanation and building on it. This package pairs a modeling engine with a reasoning protocol designed to make that harder.
The engine (axiomize) is a versioned Model IR where every quantity carries a unit, assumptions are written down rather than implied, and constraints are named checks with a stated basis. Dimensional mismatch raises with the failing checks attached, and a model that fails validation is not simulated at all. It handles algebraic, ODE, stochastic, PDE, optimization, control, network, Bayesian and causal models, calibrates to CSV data, and exports to SBML L3V2, Modelica 3.6, CellML 2.0, canonical IR JSON, Python, YAML and notebooks.
The protocol (quantum-reasoning) is a deterministic branch controller. It keeps several hypotheses alive, scores each from evidence and verification, prunes the weak ones with a recorded reason, and only collapses when the leader clears both verification and a margin. "Quantum" is a metaphor for deferring commitment; everything runs on classical hardware.
The design rule I care most about is that the system says no when it should. For the reference SIR model it cross-checks two independent methods to 1e-16, then still reports the numeric-theory check as INCONCLUSIVE because a finite horizon has not reached the asymptotic state. Plausible numbers are not the goal; checkable claims are.
Quick start (recorded run, verified against 1.2.0; current package line is 1.2.5): pip install axiomize-quantum-skills-2.0 axiomize tools # reports only backends that genuinely imported axiomize benchmark # {"status": "PASS", "passed": 12, "total": 12} axiomize-reason score --evidence 0.9 --verification 0.85 # {"can_collapse": false, "reason": "leader score below collapse threshold"}
What is in the box: a CLI with 14 subcommands, 9 console scripts, an MCP stdio server with 34 tools, a loopback-by-default REST v1 API, 15 perspective lenses, 12 domain packs, 5 report templates, 18 worked examples, and a 25-case benchmark corpus graded in CI.
Honest limits: the bundled engine is an axiomize 1.12.2 lineage snapshot, not the newest upstream engine. The npm package is a launcher shim and needs pip install first. The quickstart numbers are a historical 1.2.0 verification, labeled as such. Optional backends report UNAVAILABLE rather than substituting. Generated-code execution is not an OS sandbox.
In the past month, I have been working on creating a simulation software from scratch. The idea came to me when I was working a on a few projects that, when I looked at the math, essentially required me to solve the same kind of problems. The equation looks like the following, and it's generally referred to as generic networked dynamical system equation.
ẋᵢ = Σⱼ fᵢⱼ(xᵢ, xⱼ) + sᵢ(xᵢ, u)
Essentially, this is a graph equation. i is a node, xᵢ is a vector of states in a node, fᵢⱼ(xᵢ, xⱼ) is an edge connect nodes i to j, and sᵢ(xᵢ, u) is a source term where you can hook up an input or define a function at a node that affects itself.
I discussed this idea with a few friends before going ahead to implement; it went over the head for some, while others thought it would be interesting to see. There are applications for this in robotics, power grids, heat exchange, etc. And, the idea is inherently interdisciplinary; the node states can be from cross-domains and edges too. We can simulate a motor and it's kinematics; the motor may get heated up due to resistances, and the air pocket near it may get heated up while trying to cool it down... A real cross-domain simulation could be done with this kind of a setup.
The following is the link to the GitHub page. It's licensed under MPL 2.0.
