dylukes
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.
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.
---
You can read more about it here:
[1] https://www.sandiegocounty.gov/content/dam/sdc/pds/docs/pds2...
[2] https://www.sandiegocounty.gov/pds/docs/LightPollutionCode.p...
[3] https://www.sandiego.gov/sites/default/files/12-14-16-adopti...
[4] https://conserveturtles.org/information-sea-turtles-threats-...
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).
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.
Nintendo is using a custom OS but with a huge chunk of user space borrowed from FreeBSD. Sony on the other hand just went and forked FreeBSD outright.
You might also want to look into what OS are being used for server environments. A lot more BSD there than you might have initially guessed.
Maybe some kits beyond the ones I saw did.
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.
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 :).
[1] https://pubs.acs.org/doi/abs/10.1021/acs.jpclett.7b02621
[2] https://pubs.acs.org/doi/suppl/10.1021/acs.jpclett.7b02621/s...
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):
class Counter {
var count = 0
func increment() {
count += 1
}
func increment(by amount: Int) {
count += amount
}
...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.
These are often very at odds. And if you don't want to repeat yourself twice with two identical names... you don't have to.
And unlike Smalltalk, in Swift at least, externally unnamed but internally named is easy (just make the external name _).
In Europe no one bats an eye at you spending your entire day in cafe seating using the WiFi.
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!
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.
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?"
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
If you can then you work in a far more interesting field or place than most.
They're usually busy doing other things.
In these cases, the arrays can be just one component (could think of it as an arena) of a heap-ish structure. [1]
The cost is that your indices now need to be two dimensional (tag_idx, va_for_tag_idx). But the number of tags is known at compile time and you can optimize storage by packing so that tag_idx is the upper 4-5 bits and va_for_tag_idx uses the rest.
See: [1] https://www.cs.cornell.edu/~asampson/blog/flattening.html
Sadly the version of scheme used is very long defunct. But the goal is to get everything modernized to the point this can be something you can work with (with minimal setup and work) using the whole modern Racket ecosystem!
For the time being the REAMDE.macOS is likely to be the shortest path to getting things running. That said, it's mostly Intel specific. Running on M1 Macs presents its own set of tooling issues (to do with Racket no longer using GNU Lightning).
I still need to fully document that (unstable) process.
Currently, there's still a good amount of rough edging from the mzscheme -> Racket rewriting, and support is primarily for MacOS and Linux.
Going forward, there's a lot of modernization to be done. In particular, Racket-on-Chez no longer affords escheme.h, so there's a lot of inversion of control to be done. I'm also working on and off on an updated multi-platform rendering layer to largely replace Pad++'a X Windows drawing, with the goal being to move more of Pad++'a logic up into the Dynapad layer in Racket.
There is only a focus on "learning" until maybe 5th grade. What you do in school after that isn't making sure you learn so much as making sure you know a base set of things.
Thereafter there tend to be two types of successful students: the ones that chase A-grades ("good students"), and the ones who settle for somewhere around or just above B-grades but explore the material more freely. The key distinctions between those groups have been, in my experience, respect for authority and self discipline.
Later in life they seem to correlate with two common tropes: the person who is not superficially brilliant but can apply themselves to something for long periods of time and "just get it done", and something akin to the hacker trope: clearly intelligent, capriciously disorganize, but utterly omnivorous for any and all interesting skills and knowledge.