I've done research involving sampling from all extant notebooks on GitHub and manually analyzing them, and have been a heavy user of them in non-CS research contexts for a long time (and Mathematica notebooks for years before iPython Notebooks grew in popularity).
Having manually sifted through hundreds of randomly sampled notebooks, I feel I can confidently speak on the distribution of characteristics in them, at least up through a couple years ago.
1. Notebooks on GitHub are not necessarily an entirely representative sample of notebooks at large. If the author is putting it on GitHub, there's already a significant selection bias towards certain topics, despite notebooks being used in practically any discipline you can think of at least to some extent.
2. Notebooks in repositories that contain requirements.txt files are a minority and tend to be intended/cleaned up for sharing (itself not the norm).
3. What's more common is just a handful of !pip install at the top.
4. Even more common is just some details on dependencies in an adjoining README.
A very non-trivial chunk of notebooks on GitHub are just copies of the "Hands On ML 3" textbook/exercise set. If my memory serves there are tens of thousands of copies of that one repository. The fork count shown by GitHub doesn't account for the plethora of copies that weren't made using it.
San Diego is near the Palomar Observatory and Mount Laguna observatory (see map [1]). The observatory as well as environmental concerns of bright lighting at night messing with wildlife is why San Diego in most zones at night uses what appear to be Low Pressure Sodium (LPS) lighting. See also [2] for the current code.
However, over time these LPS streetlights started to be replaced by Induction lighting. And as of 2016, the new standard is LED based, which is supposedly even better for light pollution [3].
In areas where sea turtles nest, LPS lighting is still preferred, as it is very different from the white light from the moon they use to navigate [4].
One nice consequence for residents: as a result of the strict light pollution regulation, and the consistently clear skies, most nights one can see a surprisingly large number of stars in the sky for an urban city environment. Nothing close to a clear night far north or out in the desert, but still more stars than you might expect.
Small quibble: converting a measure to a z-score requires an assumption of normality and that you're considering a population.
For a sample the equivalent is the t-statistic, which indeed IS very often used for p-values (with the ever popular t-test) and has a decently strict list of assumptions (which, like those of [O|W|G]LS are very frequently ignored).
If I'm in the mood for being a little glib... where do you think that Linux distribution that SteamOS is based on got its user-space (or more seriously, its drivers?)
Also: the SteamDeck is by any reasonable standard a console. It just happens to run a windowed environment out of the box. Don't be that guy. If you want to pump Valve, focus instead on their contributions to the Wine project.
Addendum: the positions of the atoms shown in that video and other figures are NOT smoothed or snapped to a grid in any way. They are directly drawn from the experimental results! They really are just that clean.
This also extends to the gorgeous rotational symmetry in the "imperfections" of the outer incomplete shell, which is perpendicular to the reflective symmetry of the inner "perfect" J-27 shells.
It's very neat to zoom so far in on reality and see such a well-ordered structure.
There are applications of the Johnson solids to characterizing patterns that occur in nature at the nanoscale. You wouldn't be able to see them with the naked eye, but they are very clearly there!
For example, we observed nested J27 "shells" in the structure of the Au_146(p-MBA)_57 nanoparticle [1]. In particular, take a look at the attached .mpg video to get a clear picture of the "shells" inside this particular nanoparticle [2]. We observed three nested (two complete, one outer incomplete, corrupted by the surface protectant p-MBA) J-27 shells.
Nanoparticles like this exhibit interesting surface plasmonic effects. For smaller particles, a long standing theory was that they behave as "super-atoms", with gold atoms taking the place of neutrons and protons, and metals in the protectant shell taking the place of electrons.
While I don't subscribe to that theory, this particle in particular occupies a sort of partial transition point between the regime in which it was previously hypothesized and the regime of bulk gold where it clearly does not hold.
Disclaimer: I am a first author on this paper and produced this visualization, as well as many of the figures shown in the paper. I think the video in particular is quite neat :).
Two dozen programming languages shipped in or not, almost no languages support this.
It is something that you start appreciating a lot more once you have used it significantly. It helps a lot with writing more self-documenting interfaces that are legible at a glance.
Another detail I did not mention is that _public names are part of the interface_. This means that two functions that differ only in the public names are distinct overloads.
To give an extremely simple example (taken from Apple's docs):
This starts becoming even more valuable when you have more complex objects, and allows you to move (e.g. on some kind of repository class) mangling of overload names into more readable named argument overloads.
I had this same question while working on structural resolution of a certain RNA polymerase.
I asked "okay so if this ratcheting mechanism allows the protein to zipper along the nucleotide strand... what's pushing it along?"
The answer is that nothing is pushing it along. It's just random movement and enough time (milliseconds) plus a ratcheting mechanism to ensure it doesn't go backwards.
Our low level processes are not so different from viruses in this respect!
I don't find the first point surprising. (Our) pi is the one tied to the only metric where the unit circle is perfectly continuous, differentiable, etc.
The 2-norm is very special for many reasons I won't enumerate... and it seems apropos that its corresponding constant (pi)... for relating a distance from a point (wlog 0,0) to the result of integrating a constant around the path those points occupy/form/consist in... would itself tend to be found more than others.
Perhaps this is simply because without that continuity and differentiability everywhere of the corresponding path generated by the metric's unit circle, many other pieces would fall like dominoes.
There is something uniquely central about a concise relation between a point, a distance, and a path.
> In my book a general code review is simple sanity check by a second pair of eyes, which can result in suggestions to use different API or use an API slightly differently.
This is an impoverished view of code review. Code review is a principal mechanism for reducing individual code ownership, for propagating conventions, and for skill transfer.
A good code review starts with a good PR: one that outlines what its goals were and how it achieved them.
First item on a good review then: does the code achieve what it set out to do per the outline?
Second: does it contain tests that validate the claimed functionality?
Third: does it respect the architectural conventions of the system so far?
Fourth: is the style in line with expectations?
Fifth, and finally: do you have any suggestions as to better API usage?
A code review that is nothing more than a sanity check is useless and could have been done by CI infrastructure. Code review is a human process and should maximally take advantage of the things only humans could do. Leave the rest to machines.
An implicit question in several of the above is "will this set a good example for future contributions?"
The fundamental idea of testing units and then integrations between units is unassailable and unkillable (today).
We should have serious discussions about HOW we test units, and whether example based tests are sufficient when we can do property based testing, etc...
...but the suggestion of the idea that the unit/integration distinction has somehow been surpassed is absolutely baffling. You would need to rewrite more than half the languages in use for this to make much sense and even then I don't think you could shake this core abstraction. It's built into the tools we use and may even be built into the way we think about systems far below any language or tool choice.
This entire post could have been reduced to this (reasonably correct I think) claim.
> if we recognize that what LLMs are really doing is confabulating, we can try to compare and contrast their behaviour with that of humans
Except that the goal for the above is hopelessly misguided. If your focus in making any useful claim about LLMs or RNNs/GANs more broadly is how similar they are to human behavior you're already way off the path.
tl;dr reasonable claim, reasonable conclusion, but entirely indefensible and superstitious motivation
Having manually sifted through hundreds of randomly sampled notebooks, I feel I can confidently speak on the distribution of characteristics in them, at least up through a couple years ago.
1. Notebooks on GitHub are not necessarily an entirely representative sample of notebooks at large. If the author is putting it on GitHub, there's already a significant selection bias towards certain topics, despite notebooks being used in practically any discipline you can think of at least to some extent.
2. Notebooks in repositories that contain requirements.txt files are a minority and tend to be intended/cleaned up for sharing (itself not the norm).
3. What's more common is just a handful of !pip install at the top.
4. Even more common is just some details on dependencies in an adjoining README.
A very non-trivial chunk of notebooks on GitHub are just copies of the "Hands On ML 3" textbook/exercise set. If my memory serves there are tens of thousands of copies of that one repository. The fork count shown by GitHub doesn't account for the plethora of copies that weren't made using it.