dalke

"The times listed for dict objects are average-case times, as they assume the hash function for the objects is sufficiently robust to make collisions uncommon. They also assume the keys are well-distributed among the set of possible keys. In the worst case, when every key hashes to the same value, each of the O(1) operations below instead takes O(n) time. They also assume that hashing and comparing a key is O(1)."

Lemire's example uses a case where all of the keys hash to the same value:

   >>> M = (1 << 61) - 1
   >>> [hash(M*i) for i in range(10)]
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Here's a copy of the section on encoding methods - http://dalkescientific.com/opto_Bourne.pdf .

I got really into edge-notched cards about 10 years ago. I made my own cards for handling chemical data. You can see them at 43:41 of my talk at https://youtu.be/y6dUkCxlrd8 . I also visited the Calvin Mooers archive at UMN because of his work in Zatocoding, Chemical Zatocoding, connection tables, and substructure search (Zatopleg). He mostly published as white papers from his own company, which makes it hard to find copies anywhere else.

"Methods of Information Handling", Charles Bourne - https://archive.org/details/methodsofinforma0000unse/page/n5... (not available to read)

"Punched Cards: Their Applications to Science and Industry", https://archive.org/details/punchedcardsthei0000robe (can be checked out)

The first of these is a much better book.

They show a number of ways to encode values, such as a 5-hole triangle code, where the "O" in the following indicates a hole:

    O   O   O   O   O
      9   5   2   0
        8   4   1
          7   3
            6

    U   O   U   O   O
     \9   5/  2   0
       \8/  4   1
          7   3
            6

There were also extensions of these to handle names, used to search small (< ~10,000) literature collections, and more.

The most mathematically sophisticated is likely Zatocoding, a superimposed coding method related to Bloom filters.

The Bourne book goes into these variations in detail.

Here's a video of someone scanning in edge-notched cards for bird identification. https://youtu.be/MBwP3YOxw3I

About 10 years ago I really go into the topic and made some cards of my own, using a cutting machine to make each card, precut, from an SVG.

Not everything has easily-accessed primary sources, but many do. I think it's all too easy to fall into the trap of accepting the LLM answer because it feels right and is easy to generate. At https://freethoughtblogs.com/stderr/2025/01/18/ai-art-just-r... you'll see someone asked about which river Marbot swam across to spy on the enemy camp. It replied "Elbe". Then I did a text search of an English translation of the book and found he used a boat to cross the Danube to spy on the enemy camp, and he swam into freezing waters to save an enemy soldier.

Again, do you ask the LLM to fact check itself every single time? If that's useful, why isn't it built into the prompt? Or, if you are supposed to double-check the LLM yourself, why would you consult a secondary source if the primary source is so easy to find and search? And in that case, why not just use the primary source?

Further, if you aren't in the habit of checking primary sources then you won't have the experience to know how to find and check primary sources.

When this came up a few days ago, I spot checked the complete works of Peanuts, from a collection on archive.org at https://archive.org/details/peanutscomics19502000/Volume%201... . The consistent pattern across the nearly 50 years of Peanuts is the kids have five fingers unless obscured by orientation or objects.

You can do that yourself, and triple-check that Google AI's answer is clearly wrong.

Thus, I think it's a good example of how fact checking with LLMs can lead people astray, and the large negative externalities I mentioned combined with its well-known tendencies to make incorrect statements make it a very poor starting point when the primary source, at least in this case, is so easy to access.

If most of the sources are wrong, and LLMs are being trained on those, isn't it logical that the latter will also likely output that same wrong information?

When do you know if most of the sources are wrong, unless you yourself know most of the sources are wrong?

And that's from a training corpus which almost certainly includes statements that the kids are drawn with 5 fingers, since I confirmed that info on TVTropes and Reddit comments, like https://www.reddit.com/r/pics/comments/swod8/charlie_brown_h... .

Yet if you go to the Wikipedia entry at https://en.wikipedia.org/wiki/Peanuts you'll see the kids have 5 fingers. Or take a look at the actual cartoons. Or read the TVTropes entry https://tvtropes.org/pmwiki/pmwiki.php/Main/FourFingeredHand... under "Comic Strips".

Fact checking this with human sources is easy and not ambiguous. While LLMs are being trained that many cartoon characters only have a thumb and three fingers - it is a trope for a reason - so isn't it logical for LLMs to give the wrong answer for a comic where the human characters are actually drawn with 5 fingers?

My experience with LLMs is they keep getting things wrong, when details matter.

Do you ask the LLM to fact check everything? (In which case, why isn't that part of the standard prompt?) Or do you only ask to fact check things where you are unsure about the answer? (In which case, is it the algorithm telling you what you want to hear?) When do you stop the fact checking?

See https://tuananh.net/2026/03/05/relicensing-with-ai-assisted-... with discussion at https://news.ycombinator.com/item?id=47257803

I believe your use of "clean room" is another example of misusing the term.

Could you clarify how it was developed? Who had access to the original source code? Were code generation tools used, and if so, how? Was the PyMol source part of the training set for those tools? How did you ensure no copyright violations?

Warren was a friend of mine, and a passionate believer in open source software. He wanted people to be able to modify PyMol for their own purposes, and asked only for a license acknowledgment. Schrodinger, to their great credit, continues to honor Warren by maintaining the Open-Source PyMOL product.

If this project was not developed under true clean room practices, I ask that you continue to honor his work by including the PyMol license in your Rust rewrite.

If it was true clean room development, why does ./crates/pymol-algos/src/align/ce.rs say "This is a faithful port of PyMOL's `ccealignmodule.cpp`.", with comments like "Equivalent to PyMOL's `calcS`" and references to the original code in comments, like: "PyMOL: for (row = 0; row < wSize - 2; row++)"?

I see you interpret atom/hetatm serial numbers as an integer. Will you be using the base-36 or hybrid-36 variants (see https://cci.lbl.gov/hybrid_36/) which is a common way to handle more than 100,000 atoms?

Again, these are corner cases which come with experience. I've no expectation that a new program would handle them. I want you to know about them since they will be issues if you expect long-term uptake.

  > <price>
  $$$$

  $$$$

I talk about "$$$$" more at http://www.dalkescientific.com/writings/diary/archive/2020/0... .

Then there's the "S SKP" field, which you'll almost certainly never see in real life! I've only seen it used in a published example of a JICST extended MOLfile. See http://www.dalkescientific.com/writings/diary/archive/2020/0...

Please don't let these comments get you down! These details are hard to get, and not obvious. It took me years to learn the rare corner cases.

I also haven't done molviz since the 1990s, or used PyMol (I was VMD person), so can't say anything about the overall project. We started with GL, and had to port to OpenGL. :)

PS. A bit of history for you. PyMol's and VMD's selection syntax look similar because both drew on the syntax in Axel Brunger's X-PLOR. Warren DeLano came out of Brunger's lab, and VMD was from Schulten's group, which were X-PLOR users. (Schulten was Brunger's PhD advisor.)