https://crimson-cake-2832.nabedada3.workers.dev/index_en
I added these guided experiments because a function manual alone did not feel sufficient.
A list of buttons can explain what each operation does, but it does not really show how the behavior of a quantum system changes when one operation is followed by another. For this project, I wanted the manual itself to behave more like a small laboratory notebook: first try this, then change one condition, then compare what happened.
The idea is simple. Rather than beginning with the correct explanation and asking the reader to confirm it, begin with an operation and let the difference appear first.
For the 50-QUBIT simulator, the experiments therefore move from very simple and deterministic behavior toward increasingly complex structure:
X as a definite flip → H and its 50/50 measurement statistics → H→H → RX rotations → Bell states → GHZ states → separate entanglement clusters → merging clusters → deliberately exceeding the 8-qubit cluster limit → comparing noise conditions → measurement versus UNDO → EMERGENCY COLLAPSE.
This progression also makes the cluster-partitioning design easier to understand. Instead of explaining the engine only in abstract terms, the user can actually create separate entangled islands, connect them, watch the clusters merge, and finally force the simulator across its approximation boundary.
For the FEYNMAN PATH VIEW, I wanted to move even further away from simply showing final probabilities.
The sequence is:
H|0⟩ → H→H → H→Z→H → partial interference using S and T → comparing H|0⟩ with H|1⟩ → manually constructing a Bell state → comparing it with the ready-made Bell example → measurement → and finally asking which paths reinforced one another and which paths disappeared through cancellation.
The important point here is not merely that H eventually gives a 50/50 measurement result. The purpose is to make the intermediate amplitudes visible, so that the user can see why amplitudes must be added before probabilities are calculated.
For COMPOSITE GATES, the experiments progress through:
Bell → GHZ → SWAP → Toffoli → QFT → Inverse Circuit → the boundary between reversible and irreversible operations → and finally the difference between entanglement and CLONE.
I wanted this section to make reversibility something that can be inspected rather than simply stated. A user can compare a forward gate sequence with its inverse, see why the order must be reversed, notice why phase gates require their dagger operations, and then reach the point where measurement, reset, forced write, or noise can no longer be treated as ordinary reversible gates.
For BB84, the sequence is deliberately statistical:
No Eve with 16 transmissions → 256 transmissions → Eve with 16 transmissions → 256 transmissions and the emergence of the approximately 25% QBER tendency → following one disturbed row → noise without Eve → Eve plus noise → comparing PUBLIC TEST fractions of 10% and 30% → understanding why bases are publicly compared → comparing Alice and Bob’s final keys → and finally comparing QBER under three different conditions.
Here I especially wanted to avoid the misleading impression that “Eve means exactly 25% QBER every time.” With only 16 transmissions, the result can fluctuate wildly. Increasing the number of transmissions allows the statistical tendency to emerge naturally.
So the manuals are no longer just references for what each button does.
They are now structured as a sequence of small experiments:
Do this first.
Change one thing.
Look at what changed.
Then ask why.
That is much closer to the way I actually want to approach quantum mechanics.
I am less interested in presenting a finished answer first and then demonstrating that the simulator agrees with it. I would rather let the user touch the system, notice a difference, become slightly confused, and only then look for the explanation.
In that sense, these experiment manuals follow exactly the same philosophy as the simulator itself:
phenomenon first, explanation second.
"Look, he’s starting something weird again. But hey, I could probably do that too!" Exactly. If it’s not something anyone can do, there will never be any real progress.
Lol
My approach is: try it, see what changes, and let that difference trigger the next phenomenon. That is exactly why I come up with ideas like “50 qubits in JavaScript.”
I think most people would immediately say, “That’s impossible,” or “Are you crazy?” But often that happens because they are already looking for an answer that fits within the boundaries of what has been labeled “correct.”
I tend not to define those boundaries first.
If you plant vegetables, you may get strong winds or a long drought. So you gather whatever materials you can find and build a shelter against the rain and wind. That may fail too. Then you stack stones, raise the field slightly above ground level, build a fence, or switch to vegetables that seem more likely to survive there.
I am not starting with conditions like, “You must have a huge piece of farmland,” or “This is the proper way to grow vegetables.”
I start with what is actually there, touch it, see what happens, and change the next step from the difference that appears.
How do you build this?
For UI work like this, I usually create a layout I like in FileMaker, convert it to WebDirect, press F12, and borrow the CSS from there. Then I rebuild the interface in JavaScript.
After that, the actual simulator — quantum logic, state calculations, cluster partitioning, Feynman paths, BB84, and everything else — is built in JavaScript.
It gives me the same kind of excitement I felt when I was using HyperCard back in the ’90s.
