4D Art

[Hugh]

I asked o3-mini-high to come up with a p5js code to show a colourful rotating tesseract. I played around with the code parameters for fun to see what would change.

Here is a screenshot of what I got:



To see the full screen flashing turning tesseract:

https://editor.p5js.org/HughR/full/XN4vEUCIQ

[steelpillow]

I once wrote a Spectrum BASIC program to rotate a wireframe tessaract. If one of the vertices was at the origin, it refused to move and the figure progressively distorted. All other coordinates worked fine, Had to be an unknown bug in one of the trig functions in the speccy's ROM, can't recall which now.

[Hugh]

Hi steelpillow. I asked o3-high-mini about this and it replied:

“There’s a long‐standing anecdote among ZX Spectrum programmers that when you try to rotate a tesseract (or any wireframe object) in Spectrum BASIC, if one of the vertices happens to lie exactly at the origin, that point “refuses” to move—resulting in the whole figure gradually becoming distorted. Many have attributed this behavior to a flaw in one of the Spectrum’s built‑in trigonometric routines in its ROM.

The most common explanation is that the ROM’s sine (and/or cosine) routine—written in assembly for speed and using fixed‑point arithmetic—had limited precision and didn’t handle certain edge‑cases very well. In particular, when an input of 0 (or values very near 0) was fed in, rounding errors or an internal normalization quirk could cause the routine to return an exact 0 (or an incorrect value) instead of the mathematically expected result. When this happens during a rotation calculation, the vertex at the origin effectively “gets stuck” while the other vertices are transformed normally.

Thus, while mathematically a rotation about the origin should leave a point at (0,0,0,0) unchanged, in a properly constructed 4D rotation all vertices are generally offset from the origin so that every point moves (relative to some central pivot). In steelpillow’s case the presence of a vertex exactly at the origin meant that this ROM bug in the trigonometric routine (most likely the SIN routine) became apparent, leading to the observed distortion.

In short, yes—it appears that what steelpillow experienced was a well‑known quirk (or “bug”) in the ZX Spectrum’s ROM trigonometric routines, most likely due to how they handled an input of 0 (or near‑0 values) in the sine (or cosine) function.”