RyanCavanaugh

The internet is hundreds of billions of terabytes; a frontier model is maybe half a terabyte. While they are certainly capable of doing some verbatim recitations, this isn't just a matter of teasing out the compressed C compiler written in Rust that's already on the internet (where?) and stored inside the model.

What are you going to do with this information? What policy would you plausibly advocate for on the basis of it?

I modified hamilton_perfect_finder.py to have new values:

# 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%

And this is before any fine-tuning of the parameter set!

If you overlay 30 prime number frequency waves plus 30 more even frequency waves, you're going to have an enormous number of local peaks.

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.

The Press Secretary isn't the Supreme Court. Her say-so doesn't change the plain text of the order, and you're rolling the dice as to which any given border agent is going to choose to believe.

There's probably at least one game out there somewhere that uses Go's map iteration order to shuffle a deck of cards, and would thus be broken by Go removing the thing that's supposed to prevent you from depending on implementation details.

The problem is that people commonly don't even realize they're depending on implementation quirks.

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.

The problem with the belay test as it exists today is that it tests whether you know all the peculiarities of each gym's beliefs around things like the exact order your hands should move when taking slack, whether tails on figure 8s are important (if so, how long, and what kind of knot may or must terminate them), whether the length of the belay loop matters, and so on. These things change seemingly on a whim and aren't always motivated by good evidence.

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.

C# AOT is quite strong and would be a great choice in a lot of contexts.

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.

Our best estimate for how much faster the Go code is (in this situation) than the equivalent TS is ~3.5x

In a situation like a game engine I think 1.5x is reasonable, but TS has a huge amount of polymorphic data reading that defeats a lot of the optimizations in JS engines that get you to monomorphic property access speeds. If JS engines were better at monomorphizing access to common subtypes across different map shapes maybe it'd be closer, but no engine has implemented that or seems to have much appetite for doing so.

It's not just the overhead of showing up, it's the opportunity cost of not doing contiguous hours at a bigger job. It's very difficult to fill up a day with 45-minute jobs all over town, so he's basically working part-time if he takes a small job.

Flow doesn't even check that array access is in-bounds, contrast to TypeScript with noUncheckedIndexedAccess on. They're clearly equally willing to make a few trade-offs for developer convenience (a position I entirely agree with FWIW)

Flow's type system isn't sound either FWIW