dylukes

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.

---

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-...

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.

What do you think is running on your favorite game consoles (that aren't Xbox)? I'll give you a hint, it isn't Linux.

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.

Happy new year to all! Cheers!

I am reminded of Magnetix, though they were ball and stick based, and I don't believe included "solid" polygons.

Maybe some kits beyond the ones I saw did.

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 :).

[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...

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):

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.

It separates "names as public-facing API design decisions" from "names as developer conveniences for expressing intent and clarifying their code".

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 _).

American coffee shops have never been cafes. They're glorified caffeine dispensaries. Buy your drink, get out, drink it somewhere else.

In Europe no one bats an eye at you spending your entire day in cafe seating using the WiFi.

Good news: https://github.com/jart/cosmopolitan/commit/5e8c928f1a37349a...

Sheer random chance.

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?"

If you start enums at 1, then the first item in the enum isn't coercible to false, all items coerce to true.

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 isn’t actually correct terminology

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

I mean taking the title at face value and factoring in the odds... Practically speaking _you_ can do absolutely nothing with them.

If you can then you work in a far more interesting field or place than most.

People who are actually correct on the basis of significant experience don't tend to feel it necessary to remind others at every possible occasion (unless not doing so would lead to significant harm to others).

They're usually busy doing other things.

ALL THESE WORLDS ARE YOURS – EXCEPT EUROPA. ATTEMPT NO LANDING THERE.

AoVA lacking its own total ordering on indices might be a problem for some use cases, but not for the one that is suggested here: AST nodes.

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

Also to give a brief overview: Dynapad was/is a scheme based wrapper/GUI layer/scripting interface for building applications on top of the Pad++ primitives.

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 sure. The repo was actually just private until a moment before I commented above. The long term goal is to refactor to a point where installation can proceed with a minimal/straightforward CMake/Racket build, without any archaic dependency versions of weird hoops.

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.

Some good news for you... Pad++ and Dynapad are in a decently runnable state again! Myself, Jim Hollan, and Tom Gillespie have been on and off working on refurbishing it.

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.

https://github.com/Dynapad/Dynapad/

Consider vagrant.

In log scale yes.

Not to mention all the "Don't Bring Me Down" jokes we'll get to make.

I disagree. We associate schooling with authority. Learning may or may not co-occur with schooling depending on circumstances.

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.