HN user
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%
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.
(OP author here) Lots of people reading too much into the tea leaves here; this is just a matter of picking the best tool for this particular task, and our task (porting a JS codebase to the fastest available native target that still works in terms of not altering program structure as part of the port) is pretty unusual as far as things go
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.
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.
Yep, this. Matt Parker makes a convincing argument that multiple people have accidently performed a perfect Faro shuffle when trying to randomize a new deck of cards
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
There are plenty of hyper-competent technical people in the field who are also kind and patient. Being smart doesn't turn someone into a jerk.
I'd really like to make some video content (on-screen graphics + voice), but the thought of doing dozens of voice takes and learning to use editing software is really putting me off from it. I'd really rather just write a transcript, polish it until I'm satisfied with it, and then have the computer make the audio for me.
I'll probably end up just using OpenAI TTS since it's good enough, but if it could be my actual voice, I'd prefer that.
The existence of Photoshop doesn't mean that you can put Kobe Bryant on a Wheaties box without paying him. There's no reason that a voice talent's voice can't be subject to the same infringement protections as a screen actor's or athlete's likeness.
They've done the research and, well, the newer houses really are just better at having fewer fire deaths. I suppose it's possible the fires that do occur are worse, but on net your death rate is lower in a newer house.
https://www.nahb.org/-/media/NAHB/advocacy/docs/top-prioriti...
As expected, the coefficient estimate for the percentage of houses built after 1989 (pctpost89) is negative and statistically significant. This implies that, in counties with newer housing stock, all else equal, the fire death rate is lower. Interestingly, when identical regressions to model 1 were run using different cutoff points for new stock, such as the percentage of houses built after 1979 or 1969 or 1959, the coefficients were of roughly similar size, were always negative, and the associated t-statistics were at least as significant.
Using the same material for load-bearing and non-load-bearing parts seems like the definition of overengineering.
We've more than compensated for this in other building materials, processes, and codes. Your odds of dying in a house fire are far lower than they were even in the 1970's, let alone the 50's or 20's.
I'm here and I have no idea what you're talking about with ESM imports. Please log a bug.
Not to be flip, but if it were really all this easy, we would have done it already.
There are dozens of questions you can throw at this code: What if the input's a union? What if it's a nested union -- how do you avoid combinatorial explosion? What if the input is a function -- how do you validate its parameter types using runtime information? What if the input is a conditional type? What if you're inside a generic function? The list is enormous and it quickly gets into "you've dug too deep and unleashed a Balrog" territory once you get beyond the primitives.
Situation: There are 14 competing type representation formats
TypeScript: We can write our own type file format!
Situation: There are 15 competing type representation formats
You can use the TypeScript API to generate this information at whichever level of detail you want.
The level of detail TS has about types during the checking phase is much higher than you would want in practice for 99% of projects (e.g. 1 + 2 + 3 has 6 different types associated with it).
The level of detail TS has about types during the checking phase is potentially lower than you would want in practice for a lot of projects (which is critical since that makes the whole feature useless if that happens). For example, the list of properties of a particular generic instantiation is lazily computed, but it's possible your program never pulls on the list so it never exists in the first place, yet is something your type-based tool might want to know.
TypeScript dev lead here.
Today, you can already write a program using the TypeScript API to inspect all of this information to accomplish whichever scenario is at hand. The existence of all these tools, each with different opinions on design direction and implementation trade-offs, demonstrate that this is possible. Yet it's not demonstrated how those tools would benefit from reading from a data file as opposed to using the TypeScript API.
Something like api-extractor has different constraints from io-ts which has different constraints from typescript-schema. The API exists today and is apparently sufficient to meet all these tools' needs, yet what's proposed is a data file that can encapsulate any possible operation you might perform with that API.
Having TypeScript try to imagine, implement, and maintain a data file format that can satisfy _all_ of these tools' use cases, plus any future tool's use case, is a tremendous effort with no clear upside over using the existing API.
It's easy to gain support for the idea of "put the types in a file" because anyone reading that can imagine a straightforward implementation that just achieves their particular goals, but everyone's goals are different and the amount of overlap is not actually all that high when you look at the wide breadth of tools in the list. There's a very different amount of information you'd need to enable a type-aware linter (which is basically type info on every expression in the program!), as compared to a simple documentation generator (which might only need top-level declaration info).
Things rarely change at all once they're at stage 3. That's why TS waits until that stage before implementing. There might be a minor tweak in some edge cases but stage 3 is usually "done".
Runtime type systems: TS has none; C# has extensive RTTI
Function dispatch: TS is purely dynamic; C# has both static and dynamic
OOP: Mandatory in C#, optional in TS
Variance: Implicit in TS, explicit in C#
Numeric types: TS has one (number); C# has the entire signed/unsigned/float x 8/16/32/64-bit matrix
There's really no intentional effort to converge them.
The US military made no claims that these videos showed unexplainable phenomena. They just sort of put them out there.
The video they called "Gimbal" shows an artifact caused by a gimbal mechanism, for example
Great, where's the data? Right, he doesn't have any, and is asking for other people to come forward with the data.