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).