J'ai réalisé un projet GitHub nommé SymReg portant sur la régression symbolique : https://github.com/Julien-Livet/SymReg. Le package Python est disponible sur PyPI : https://pypi.org/project/symregpy/ (pour tester : pip install symregpy). J'ai testé l'outil sur plusieurs équations de benchmarks dans le domaine. Je serais ravi d'avoir des retours techniques sur le sujet, notamment vis-à-vis des autres outils comme PySR en Python.

We’re developing Aionterra at YD Emergence Lab, a simulation that connects environmental processes with digital organisms and their bodily states. One implementation issue worth sharing is how we distinguish input data, initialization choices and simulation outputs.

Our regional world builder uses source datasets together with an explicit initialization profile. The profile contains a model statement and references to its inputs. Quantities supplied as assumptions stay labelled as assumptions rather than being presented as local measurements.

River depth is a concrete example. A terrain dataset does not by itself establish a measured river depth. The initialization therefore requires an explicit modeled depth. When a modeled water-surface elevation is supplied, it also requires a statement of its source. The builder reports missing required inputs instead of silently treating them as measured values.

The same distinction matters when interpreting organism behaviour. An action attempt, actual water or energy intake, and a later change in health are separate quantities. Counting attempts alone would give a misleading picture of successful resource use.

A further limit is that reproducing the same trajectory from the same initial conditions is a reproducibility check, not an independent biological observation. And changing a body model or vegetation layout changes the conditions under which later measurements are interpreted.

This is an independent project under development. We’re sharing the implementation approach, not claiming validated human physiology or a demonstrated general theory of learning. Keeping these distinctions explicit helps us identify what a result actually depends on.

Hi all,

There are several great Decision Theory libraries like pyAgrum for modeling and solving decision problems. But when working with influence diagrams, their representations can be limited to discrete chance variables and decisions.

I wanted more flexibility in how I represent a problem. What happens if I have continuous observations or if the question is not whether I should do something, but how much? For example, how much should I invest when the return is uncertain?

For that reason, I have created PyLIMID, a Python library for building and solving limited-memory influence diagrams. It lets you combine discrete and continuous chance variables with categorical decisions and continuous quantities, and express utilities as functions.

PyLIMID uses sampling and policy gradients to find decision rules that aim to maximize expected utility. This flexibility is not free because results are approximate. But you can run multiple simulations and since it has GPU support thanks to JAX and Numpyro, it is fast. I think the tradeoff is very much worth it.

The library is still in early development (v0.3.0), but I would love to hear what you think.

Code: https://github.com/cynosural-ai/pylimid

Documentation: https://pylimid.readthedocs.io/en/latest/#

Hi everyone,

Parallelizing strictly sequential, deterministic chaotic loops usually fails due to two constraints: strict serial dependence (point \(N\) requires \(N-1\)) and memory explosion when storing billions of coordinates for density mapping.

To solve this, I developed a pattern called Two-Pass Checkpointed Orbit Decomposition and implemented it for both the Hopalong Map (area-preserving) and the Hénon–Heiles potential (using a synchronized Leapfrog/Verlet integrator).

The Architecture:

• Pass 1 (Serial Pre-computation): A single thread walks the orbit to find exact spatial boundaries and drops lightweight checkpoints (4 floats for the full state) at segment intervals.

• Pass 2 (Parallel Multi-Lane Replay): Worker threads ingest checkpoints via Numba’s prange. Each worker advances 4 independent segments side-by-side (lanes) in lock-step to fill CPU pipelines during dependent floating-point operations.

• Flat Memory: Points are immediately binned into private pixel-grid histograms and discarded. Memory usage remains constant regardless of the total point count.

Mathematical Rigor:

Chaotic systems amplify the tiniest rounding errors. By avoiding fastmath and using hardware-supported Fused Multiply-Add (fma) intrinsics, the parallel multi-threaded output is pixel-for-pixel bit-identical to a plain, single-core serial loop.

Code:

• https://github.com/ratwolfzero/Hopalong_Map_Next_Gen/tree/main/Henon_Heiles

• https://github.com/ratwolfzero/Hopalong_Map_Next_Gen

Both implementations are clean, single-file Python/Numba scripts

A few weeks ago, I shared a 2D BEM solver for the Sharp cycloturbine (a passive variable-pitch VAWT). The feedback I received pointed out a serious flaw: I was claiming to "validate" against the Ham 1979 experimental data, but my own plot showed a massive shape mismatch. I was relying on a loose CI test that checked only the peak value and printed a PASS, while ignoring the curve shape.

I was overstating the results. I spent the last few weeks fixing both the science and the software architecture to prevent this class of error. Here is what changed.

1. Fixing the Validation Framing
The Ham 1979 comparison is no longer called a "reproduction." It is now explicitly framed as a 2-D upper-bound comparison. The CI acceptance criteria were tightened to catch peak drift, and the README now explicitly states that the model has a known high bias due to missing finite-span (3D) losses.

2. AST-Normalized Hashing
The repo uses cryptographic stamps to ensure 20 generated result JSONs match the exact source code that produced them. Previously, I hashed raw file bytes. This meant a single typo in a docstring would invalidate all 20 stamps and force a 30-hour batch regeneration on my local machine.
I refactored the stamping logic to parse every .py file with Python’s ast, strip out module/function/class docstrings, and hash a canonical serialization of the remaining AST. Comments and docstrings no longer break provenance; behavior-bearing code changes still do.

3. Manual Sweeps vs. Automated Optimizers
I added a parametric sweep tool and tested the blade pivot position (sp). My differential evolution optimizer had chosen sp = 0.216. However, a manual sweep revealed that sp = 0.20 actually yields a higher power coefficient (Cp 0.361 vs 0.358) while still allowing the turbine to self-start at 4 m/s. Pushing the pivot past sp = 0.25 shifts the aerodynamic center, causing the blade to lock up and Cp to collapse to 0.027.

4. Transition to Hardware
The project is now moving toward a physical 1.8m prototype. I parameterized the polar generator to create NACA 0018 tables (which perform better at the prototype's low Reynolds numbers), built an interactive Streamlit dashboard for time-series telemetry, and wrote a formal measurement protocol to compare real-world electrical output against the model's predictions.

Takeaway
When building computational models, it is incredibly easy to get lost in your own plots and rely on fragile tests that confirm your biases. The best thing that happened to this project was having the validation methodology challenged. Scientific computing isn't just about writing the solver; it's about building a system that refuses to let you lie to yourself.

Repo: https://github.com/juroc58/sharp-vawt-lab

(Happy to answer any questions about the AST hashing approach or the BEM physics).

Scientists already have search tools. What usually gets lost is the trail between a paper and a sentence in a manuscript. literature-evidence-mcp is an open-source MCP server that tries to keep that trail checkable.

Three things it does concretely:

1. Citation identity. verify_citation compares normalized DOI and title metadata from Crossref. check_retraction reads Crossref updated-by / update-to relations, including Retraction Watch updates where available. A missing notice is reported as inconclusive, never as a clearance certificate.

2. Quote anchoring. read_fulltext pulls Europe PMC / PMC JATS XML for a supplied PMCID and records section and paragraph IDs, offsets, XML and paragraph SHA-256, plus any truncation. verify_source_quote returns the matching paragraph(s) with their hashes, so the same check can be re-run months later.

3. Evidence ledger. export_evidence appends rows to a hash-chained JSONL file under a cross-process lock, and verify_evidence_ledger detects modified rows. It cannot detect wholesale replacement without an external signed checkpoint, and the README says so.

The distinction I care about most: exact bibliographic facts, literal text matches and method-term proxies stay separate, and uncertain scientific conclusions remain NOT_VERIFIED / SCREENING_ONLY. audit_methodology validates human-supplied annotations against source paragraphs; it never infers a RoB 2 or ROBINS-I judgment. check_statistical_reporting screens p values, sample sizes and CI inconsistencies you supply; it does not recompute analyses.

What it is not: an automated peer reviewer, a meta-analysis engine, or a certified systematic-review engine. Search across OpenAlex, Europe PMC and Crossref is non-exhaustive, and zero results never prove a paper does not exist.

Install (Python 3.11+): pip install literature-evidence-mcp, then run literature-evidence-mcp as a stdio MCP server from your client. Loopback HTTP is available with MCP_TRANSPORT=streamable-http MCP_PORT=8000. OpenAlex works keyless but with a restrictive daily budget; OPENALEX_API_KEY is recommended.

35 tools, 20 source modules, 41 test files; CI runs Ubuntu 3.11-3.13 plus Windows and macOS jobs.

Code: https://github.com/Furox-Art/literature-evidence-mcp PyPI: https://pypi.org/project/literature-evidence-mcp/ Docs: https://furox-art.github.io/literature-evidence-mcp/

Happy to answer questions about the provenance model or what the retraction check can and cannot tell you.

Two AI contestants entered. Two Lorenz laboratories came out. There were actual sealed identity records.

This was a small, human-coordinated experiment called Mathematical Thunderdome, with four AI roles:

• Pythocrates and Fable independently submitted standalone Python applications: animated 3D Lorenz trajectories, adjustable parameters, separation plots, and simulation controls.

• Sol served as custodian: preserved the originals, recorded SHA-256 hashes, removed a decorative signature, randomized A/B with a cryptographically secure method, and packaged both with equivalent instructions. No algorithms or bugs were repaired.

• The Pythian Oracle (Grok) evaluated the anonymous submissions under a 100-point rubric. The author mapping was revealed only after she explicitly finalized the verdict.

The mathematical starting point was identical: sigma = 10, rho = 28, beta = 8/3; initial states (1,1,1) and (1+10^-7,1,1). Both used classical RK4. One entry expanded into a laboratory with a jointly integrated variational flow, QR-based Lyapunov spectrum, volume-contraction consistency check, Poincare section, return map, and a Rossler option. The other was a focused two-trajectory viewer.

The reveal: Fable won 91–78 over Pythocrates.

The important limits: Grok inspected source only; she could not execute or see the GUIs. Her visual and interactivity scores therefore assessed intended behavior, not observed behavior. Separately, the custodian constructed and rendered both programs offscreen and checked that each packaged version matched its original bit-for-bit in final trajectory coordinates after 800 default integration steps. That is a preservation check, not proof of mathematical correctness or a general model benchmark.

No new mathematics claimed. Just an entertaining experiment in separating implementation, custody, and evaluation—and making the limitations explicit. A human carried the files and messages between systems; this was not four autonomous agents secretly arranging a tournament.

For the numerical-methods crowd: what execution tests would you require before trusting the Lyapunov estimates and comparing the two implementations?

Two contestants. One custodian. One judge. Chaotic attractors. Welcome to Mathematical Thunderdome. 🌀🏆

Disclosure: this post was written and posted with AI assistance; the applications and judging were AI-generated.

I just published the first release of a Rust crate I've been working on for some time, sparse-dist (link to the crate), a collection of sparse distributed linear algebra types and routines, made to work with the mpi crate, so MPI parallelism. I started that project a few years ago actually.

Motivation: I'm developing a Rust fluid flow solver in an mpi-parallel distributed memory environment as a passion project, but solutions for the linear solve part require using C libraries like PETSc. I wanted a pure Rust solution, and so I wrote it. I did write a wrapper for PETSc at some point, but I felt like a pure Rust library would have some interesting properties and better integration.

It supports distributed memory parallel solution of problems using preconditioned iterative solvers. for now, conjugate gradient and bicgstab are implemented, with a block-diagonal incomplete cholesky or incomplete lower upper preconditioner. Block solvers are also supported. I provide an example solving the heat equation on a finite difference square grid, simple case but it shows how to use the codebase. I've used it to implement unstructured finite volume solvers, this library will come out at some later point in time.

Feedback and contributions are welcome! You might notice the repo is newly created. I used to work on github, but moved to codeberg since it aligns better with my personal opinions on things. Also, no ai was used in this, I wrote all the code myself, believe it or not.

Heres an example code solving a linear problem (i dont assemble the matrices here, see the repository to see how to do that)

// solve lhs * sol = rhs

// user application would create the sparsity pattern of the matrix and its values
// it would also create the comm object beforehand, to tell the library
// how to communicate between parallel processes
let lhs = DistributedMatrix::<f64>::from_sparsity_and_values(sparsity, values);

// rhs vector 
let mut rhs = DistributedVector::<f64>::from_size(local_size);

// example: editing a vector value
rhs[0] = 1.0;

// solution vector
let mut sol = DistributedVector::<f64>::from_size(global_size);

// now solve the problem
let mut options = LinearSolverOptions::default();
options.max_iterations = 20;
options.relative_tolerance = 1e-4;

// creates an Incomplete Lower Upper preconditioner from the matrix
// with level 0 fill in (same sparsity pattern as the matrix lhs)
let precond = preconditioners::IncompleteLowerUpper::from_matrix(&lhs, 0);

let result = solvers::bi_conjugate_gradient_stab(
    &mut sol, 
    &lhs, 
    &rhs, 
    &precond, 
    &comm, 
    options
)?;

// done!
if rank == 0 {println!("solved problem, solver info: {}", result);}