Readit NewsTherefore it's not relevant and not needed for the public to know.
Look at a chart of sin(x) + sin(x/2) + sin(x/3) + sin(x/5) + sin(x/7) + sin(x/11) + sin(x/13) + sin(x/17) + sin(x/19) + sin(x/23) + sin(x/29) + sin(x/31) + sin(x/37) + sin(x/43), you can find a local peak close to practically any number; the chart is effectively entirely composed of peaks.
It's extremely unsurprising that you would find peaks near mathematically relevant numbers, since there are peaks near any number whatsoever. You could pick ten random numbers out of a hat and fine tune those to 99.999%+ accuracy as well using the same scaling procedure.
# Target constants CONSTANTS = { 'fine_structure': 131.11, 'phi': 1.9, 'pi': 3.6, 'e': 2.4, 'sqrt_2': 1.1, 'sqrt_3': 1.2, 'sqrt_5': 2.5,
Best results: L = 3017.391610 s = 0.042000 Average: 94.848564% Minimum: 82.509479%
Constants:
sqrt_2 : 100.00000000%
sqrt_3 : 99.99236291%
phi : 99.93928922%
pi : 99.89806320%
e : 99.88623436%
sqrt_5 : 99.85340314%
Look at a chart of sin(x) + sin(x/2) + sin(x/3) + sin(x/5) + sin(x/7) + sin(x/11) + sin(x/13) + sin(x/17) + sin(x/19) + sin(x/23) + sin(x/29) + sin(x/31) + sin(x/37) + sin(x/43), you can find a local peak close to practically any number; the chart is effectively entirely composed of peaks.
It's extremely unsurprising that you would find peaks near mathematically relevant numbers, since there are peaks near any number whatsoever. You could pick ten random numbers out of a hat and fine tune those to 99.999%+ accuracy as well using the same scaling procedure.
It's almost always unintentional. Someone wrote some code, it works, they ship it, not realizing it only works if the list comes back in a specific order, or with a specific timing. Then a year or two later they do some updates, the list comes back in a different order, or something is faster or slower, and suddenly what worked before doesn't work.
This is why in Golang, for instance, when you iterate over map keys, it purposely does it in a random order -- to make sure that your program doesn't accidentally begin to rely on the internal implementation of the hash function.
ETA: But of course, that's not truly random, just pseudorandom. It's not impossible that someone's code only works because of the particular pseudorandom order they're generating, and that if Golang even changes the pseudorandom number generator they're using to evade Hyrum's Law that someone's code will break.
For example, they write code that unintentionally depends on some distantly-invoked async tasks resolving in a certain order, and then the library implementation changes performance characteristics and the other order happens instead, and it creates a new bug in the application.
Climbers still complain about the belay test, especially older climbers who cut their teeth outdoors and same late to the gym scene. But most gym accidents involving top roping or lead climbing are going to come down to a failed safety check or a mistake on the part of the belayer. And a failed safety check is at least partially a belayer failure.
Experience level doesn't necessarily correlate with safe technique. Beginners can be highly conscious of the consequences of a fall, where more experienced climbers can get complacent and sloppy when the negative consequences fail to materialize.
For example: the coach of an internationally competitive athlete dropped his climber on a grigri because he was casually chatting with someone on the ground and failed to control the brake strand.
I learned to belay at Vertical World in 2005 and would fail Vertical World's belay test today, for multiple reasons, if I used the same method they themselves taught me!
Meanwhile, as you point out, no test can determine whether or not a person will be paying attention during an actual climb.
Go was just very, very strong on port-friendliness when coming from the TS codebase in particular. If you pull up both codebases side-by-side, it's hard to even tell which is which. C# is more class-oriented and the core JS checker uses no classes at all, so the porting story gets quite a bit more difficult there.
I would also recommend reading kdy1's observations when faced with the same task: https://kdy1.dev/2022-1-26-porting-tsc-to-go . The only caveat I'd add is that I can't tell where the 62x measurement in that post came from. Our own experiments doing Rust and Go implementations showed them within the margin of error, with certain phases being faster in one vs the other.
It is a research topic for heaven's sake:
https://arxiv.org/abs/2504.16046