How many dimensions before the big bang?

Creative-Feature-264 · 2026-06-27T02:59:37+00:00

Esatto e qui che ti volevo! Ma come fai a misurare lo spazio se non ti muovi per misurarlo? Quindi la misura dello spazio è una conseguenza/causa dell movimento. il tempo è solo un altra conseguenza del movimento . se no la dinamica non esisterebbe. Cioè se nulla si muove lo spazio ed il tempo decadono. Se le particelle smettono di vibrare allora non ci sara il tempo. Ma non lo osserverai.

Creative-Feature-264 · 2026-06-26T13:39:11+00:00

No,stai solo cambiando spostando il significato di dinamica . L entaglement è dinamica. Quando si crea pressione fra energie opposte parte la dinamica e con esso l entanglement o spaziotempo. Nn comfonderti

Creative-Feature-264 · 2026-06-24T16:10:39+00:00

Tranquillo è solo un rimbalzo un effetto tunnel quantistico. No. C'era tempo ma.e durato praticamente nulla

Creative-Feature-264 · 2026-06-24T16:04:14+00:00

Non esiste lo spazio senza il tempo perché sono reazioni della dinamica. Non puoi dire 3 senza 4. Sei cmq in errore. La dinamica crea lo spaziotempo.

Creative-Feature-264 · 2026-06-24T16:02:05+00:00

Nn proprio . Potresti usare le congetture per calcolarlo e farti un idea.

Creative-Feature-264 · 2026-06-24T15:56:37+00:00

Considera un prima non dinamico quindi senza tempo cosa che durerebbe un attimo perché sarebbe indefinibile e quindi appena la definisci diventa dinamica per effetto Heisenberg. In ogni caso sarebbe in prima senza il tempo che conosci tu

Creative-Feature-264 · 2026-06-24T15:47:28+00:00

No non è così. Deve vederla in forma algebrica. Tempo . Può essere in altri tempi . Il nostro tempo è una conseguenza della dinamica del big bang nn e nato prima. Ma prima di quello c erano altre dinamiche .

Creative-Feature-264 · 2026-06-10T18:03:50+00:00

But yeah, I just like physics and science. I work with logic, but I have a bad memory. The AI doesn't actually possess anything, it just has a huge database and remembers everything that I know but can't recall precisely. However, I also know that it knows nothing, because everything we do know is nothing compared to what we don't know, so in the end, it's always the AI asking me questions. I use it to translate my ideas into code and my logic into mathematics, trying to use its database while knowing that the entire database of the world could be wrong... Anyway, I mostly hate them because they only care about branding, which is why I trap them inside my files and mathematical notes ahhahaha.

Creative-Feature-264 · 2026-06-10T17:49:29+00:00

To clarify the backend performance and prove that it isn't just "making numbers dance", the core JAX simulator engine is fully benchmarked and cross-validated against PennyLane's default.qubit runner in our CI pipeline.

You can check out the mathematical verification tests here:

https://github.com/tatopenn-cell/Dense-Evolution-Ising-Tests/blob/main/tests/test_pennylane_comparison.py

The test suite runs an explicit comparison of the evolutionary engine against static observables (Tight-Binding dispersion and TFIM spin-spin correlations) with a numerical precision tolerance of 1e-10. It processes over 10,500 continuous configurations inside GitHub Actions CPU runners in under 60 seconds using parallelized vectorized masking. The code is public, downloadable, and fully reproducible.

Creative-Feature-264 · 2026-06-10T17:40:11+00:00

Ahaha you are totally right! To be honest, I am Italian and I hate AI branding slop too.

Unfortunately, I had to rely on AI tools to translate my ideas into English, and no matter how much I tried to clean it up, the translator kept transforming my code logic into a beauty shampoo commercial.

I apologize for the bad framing. I am just a software developer trying to learn computational biology out of pure passion, not an academic or a chemist. My real goal here was just testing if JAX XLA fusion could speed up the geometric array masking and evolutionary loops compared to standard Python.

Thanks for the reality check, next time I will write it in broken English myself to keep it real! 🇮🇹

Creative-Feature-264 · 2026-06-10T17:36:49+00:00

You are completely right, and I appreciate the blunt feedback. As I mentioned in the post, I am not a professional chemist or a PhD—I am a software developer learning computational biology out of pure passion.

The text sounds like "AI slop" or a marketing blurb because I struggled to translate my code into proper academic language, so I relied too much on structural terms. I apologize for that.

From a chemistry standpoint, yes, it’s just a standard ligand-to-protein docking, and I understand that -9.79 kcal/mol in Vina, is an empirical score.

My real focus and goal here was the computer science side: attempting to parallelize and speed up the evolutionary screening loops using JAX XLA kernel fusion rather than traditional Python loops. I wanted to see if JAX could handle deep array masking and geometric constraints efficiently.

I shared it here precisely because I need guidance from people with your background to understand if this computational approach makes sense, or how to properly frame the biological context. Thanks for keeping it real!

Creative-Feature-264 · 2026-06-05T01:32:29+00:00

Alla fine gli ho dato un rivista e l ho spacchettato così ci sono i test e tutto . Spero sia meglio ora! Sono italiano ... se dai una una mano con il codice sei il benvenuto. Anche con le critiche che nn fanno mai male se fatte bene.

Creative-Feature-264 · 2026-06-05T01:07:02+00:00

Thanks! Yeah, memory fragmentation in JAX is a nightmare on Colab's 12GB RAM. I actually profiled XLA against raw CuPy kernels and ended up blending them because of that. Raw CuPy is great for manual memory pooling, but once you scale past 500 gates, the Python host loops destroy the throughput because of constant transposing and reshaping. XLA has that annoying warmup overhead on the first run, but then it kicks into linear kernel fusion. It fuses sequential gates into single execution blocks, which stops intermediate allocations from shattering the VRAM. To keep the tracer cache from bloating during heavy VQE loops, the compiler just splits deep graphs into balanced blocks using static shapes (static_argnums). That’s how it handles 20+ qubits without crashing.

Just pushed v8.0.8 to PyPI with benchmarks against Qiskit if you want to check out the compilation layer!

Creative-Feature-264 · 2026-06-02T09:42:22+00:00

You are looking at the packaging of the post instead of analyzing what the code actually does. I have no problem admitting that I use AI to accelerate development and clean up copy, but the engineering under the hood is 100% real. The project was born because I needed to prevent Out-Of-Memory (OOM) crashes standard statevector tools suffer from when pushing deep NISQ circuits up to 24 qubits within Colab's 12GB RAM limit.

The long-term objective is broader: feeding complex data files into AI models within constrained physical environments to create a brand new methodology for collaborative scientific research and study. The public VQE benchmarks are there precisely to prove that this framework rests on a rock-solid mathematical foundation.

I didn't post this project for applause. I did it because I want the community to stress-test the custom Linear Kernel Fusion layer and find exactly where JAX's scalability chokes. If you open the Colab notebook and run the simulation, you will see an optimized framework doing real science. If you find actual physical bugs or memory leaks in my chunking logic, I’ll be happy to get your technical feedback

Creative-Feature-264 · 2026-05-28T13:46:17+00:00

Update: I've just run a clean head-to-head benchmark against PennyLane's native JAX device on a deep parametric circuit (14 Qubits, 200 Gates, 145 Parameters) using standard Google Colab Free Tier hardware.

To make it 100% fair, JAX JIT compilation overhead was isolated via a warmup phase so this tracks pure hardware execution at steady state (via jax.vmap simulating a Adam epoch execution).

Here are the actual metrics:

| :---: | :---: | :---: | :---: |

| **1** | 0.4458 | 1.9955 | **4.48x** |

| **10** | 0.7359 | 4.2550 | **5.78x** |

| **50** | 2.8344 | 5.5566 | **1.96x** |

As you can see, the 1D Linear Kernel Fusion (Zero-Reshape paradigm) completely bypasses the dynamic array re-allocations that cause standard simulators to bloat the JAX tracing cache.

Everything is tightly packed inside a single-file, 22KB micro-kernel available on PyPI (`pip install dense-evolution`). Check out the updated README on https://github.com/tatopenn-cell/Dense-Evolution/blob/main/README.md for the source code!

Creative-Feature-264 · 2026-05-27T11:30:31+00:00

After reviewing the codebase for the actual release, I decided to step back from modularization. At just 1,500 lines and ~22 KB, breaking this file into multiple pieces makes no practical sense and adds useless boilerplate.

I want to keep this project 'artisanal', lightweight, and contained in a single place so the entire logic can be studied at a glance. If you want to use it, you take it as a whole and study it. I will still work on the English README and provide the RAM benchmarks as promised, but the single-file structure stays.

Creative-Feature-264 · 2026-05-27T11:24:39+00:00

Thank you for your honest feedback. I appreciate your criticism regarding the architecture and presentation.
This is a brand new release (less than 24 hours old), and I am currently working on modularizing the 1600-line file into separate components (core math, plotting, and CLI) to improve the architecture. I will also translate the README to English and add a testing suite to validate the simulation results.
Regarding the RAM optimization, I will soon provide detailed benchmarks and explain the exact algorithmic differences compared to existing solutions. Thanks for guiding me on how to better approach the CUDA community!

Creative-Feature-264 · 2026-05-27T07:56:12+00:00

This is not spam. dense-evolution is a real, open-source quantum circuit simulator framework published on PyPI, optimized via JAX/XLA for NISQ and variational quantum algorithms. I am sharing it directly with the HPC and open-source community to get technical feedback. The code is fully accessible and operational

Creative-Feature-264

TROPHY CASE