Or is this mostly a problem when you actually want to calculate the eigenvectors themselves, and not just matrix functions?

There are leagues around some games (like the ones mentioned in the article). There are also events with "league" in the name that are not really leagues (like ESL Pro League). In any case, none of them are financially successful in the US.

There already is an implicit "branch" on every array access in C, it's called an access violation.

Do they test for a segfault on every single array access in the code base? No? Then they don't really have 100% branch coverage, do they?

Have you considered that you may just be very out of touch?

>Photons are bosons and therefore are very reluctant to interact, essentially requiring nonlinearities.

Please don't throw out random sciency terms. First of all, interaction is pretty much by definition nonlinear. Second, photons are not reluctant to interact. Photon-photon scattering is negligible (which has nothing to do with them being bosons, as gluons and mesons readily demonstrate), but nonlinear optics doesn't rely on photon-photon scattering.

The most famous example is FORTRAN, until 1990 when they added RECURSIVE directive.

Generally, I would recommend against -ffast-math mostly because it enables -ffinite-math-only and that one can really blow up in your face. Most other flags (like -funsafe-math-operations) aren't that bad from an accuracy standpoint. Obviously you should not turn them on for code that you have actually tuned to minimize error, but in other cases they barely ever degrade the results.

Sadly, I feel like SR can only really be "understood" as a complete theory. All the individual phenomena (time dilation, length contraction, relativity of simultaneity, constant speed of light etc.) are very hard to understand, because you cannot just take one of them and add it to classical relativity without immediately running into paradoxes. Only once the whole picture is known you see that all the pieces beautifully imply each other. This problem applies to every approach to the subject I've seen.

So what have we really gained? Since we still need the extra assumption that an invariant speed actually exists, we could've just gone the other way and done the light clock calculation to get the Lorentz transformation instead.

ALGOL 68 had some form of array slicing as well, but I'm not sure how influential it really was in this department.

Generate two independent doubles a and b the "usual way", meaning from [0, 1) with equal spacings of 2^-53. Then calculate 2^-53*b + a. Assuming for simplicity that the rounding mode is towards zero, this gives a new random double in [0, 1). I've only done the math in my head so I'm not 100% sure on all the numbers, but I believe it scores pretty well at the criteria in the blog post; tentative results are

Probability of zero: 2^-106

Smallest nonzero: 2^-106

Largest non-seeable: approx. 2^-54

Distinct values: 2^58.7

The usual rounding mode (round to nearest, ties to even) will generate numbers in [0, 1] with very slight biases that need closer analysis. One could also go further and do e.g. 2^-106*c + 2^-53*b + a, but something like that should only be needed for for single-precision floats.

The obvious downside is that you always need two random integers and not just in the slow path. However, SIMD becomes easier because you don't need AVX512 for lzcnt.

I do have to question the choice of right-to-left (array language) evaluation order. I've personally always preferred left-to-right (stack language) evaluation. I feel like right-to-left requires you to think to the end of a line before you start typing anything at all, as the first thing you type is the last thing that's evaluated. Left-to-right would also allow re-evaluating and visualizing the stack as you write each operator.

The biggest issue I can see right now is matching up the starting piece with the previous puzzle's ending piece, but I feel that should be manageable with some heuristics and brute force. And one would have to test whether the puzzles generated like this are actually "random-looking" enough.