H/W = W/(H/2)       (halving long side H and flipping maintains aspect ratio)
        = 2W/H          (multiply numerator and denominator by 2)
    H²  = 2W²           (multiply both sides by HW)
    H   = √2·W ≈ 1.41 W (take the positive square root; H, W > 0)

Performance, when records are complex and usually not accessed.

Ease, avoiding/postponing table design decisions.

Flexibility, for one of many corner-cases (since sqlite is a very broad tool).

Incremental enhancement, e.g. when starting with sqlite as replacement to an ndjson-file and incrementally taking advantage of transactions and indexes on fields [1,2,3].

For example, several of these could apply when doing structured logging to a sqlite database.

    [1]: https://www.sqlite.org/expridx.html
    [2]: https://www.sqlite.org/gencol.html
    [3]: https://antonz.org/json-virtual-columns/
    See also: https://www.sqlite.org/json1.html

[0]: https://github.com/agronholm/typeguard/

[1]: https://typeguard.readthedocs.io/en/latest/userguide.html#us...

[0]: https://www.python.org/dev/peps/pep-0638/

https://en.wikipedia.org/wiki/Magnetic_dipole

https://en.wikipedia.org/wiki/Magnetic_monopole

Git uses SHA-1, a hardened version since 2017, and are now doing per-repo upgrades to SHA-256 [0]. Lots of repos are presumably still on SHA-1 (and users on older versions of git).

As of 2020, chosen-prefix attacks against SHA-1 are now practical. [verbatim from 1] But I don't think second preimage attacks are practical yet.

Linus Torvalds argued in 2006 basically that it's irrelevant whether git's hash function is second preimage resistant. Selective quoting:

> remember that the git model is that you should primarily trust only your _own_ repository [2]

> [a malicious] collision is entirely a non-issue: you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's _literally_ no different from the attacker just not having found a collision at all [2]

All that is just to say: git originally chose its hashes for the above mentioned "git model", thus didn't 100 % care about second preimage resistance. For your suggested search engine, depending on how the database is collected you might not be able to trust "your own repository" (if it's crowdsourced I could register another codebase with the same hash as Linux). A second preimage resistant hash function would be a requirement for the suggested use case.

[0]: https://git-scm.com/docs/hash-function-transition/

[1]: https://en.wikipedia.org/wiki/SHA-1#cite_ref-8

[2]: https://marc.info/?l=git&m=115678778717621&w=2

[0]: https://www.youtube.com/watch?v=1OfxlSG6q5Y

The doc would be at least 20 % more useful to me if the pdf had a table of contents. Should be easy to include assuming that it was written with latex. Opinion: when writing a lengthy latex document, the extra 0.5 % of work required to add automated pdf metadata (table of contents, clickable references) has outsized usability effects.

I stumbled upon typos:

* "Basel problem formula": pi should be squared.

* The "more general" statement related to Bayes theorem lacks a right parenthesis.

Since Python imports can have side effects, the order can matter. But to the extent that it doesn't break anything, alphabetically sorted groups seems deterministic and readable.

I think this might be the most popular implementation for auto-sorting: https://pypi.org/project/isort/

But interestingly, every relevant comment here either got something wrong about the final frequency or percentage, or corrected the wrong thing. (Parent comment, grandparent, 2 aunts and 1 cousin.)

0.5^10 = 2^-10 = 1/(2^10) = 1/1024 [i.e. exactly 1 person per 1024] ~= 0.00097656 ~= 0.09766 %.

I recommend adding bookmarklets for Wayback Machine: https://en.wikipedia.org/wiki/Help:Using_the_Wayback_Machine...

I got curious if/how deafblind people learn to communicate in the first place, if they are completely deafblind from birth. If humans can learn not just communication but language without either vision or hearing, that seems to suggest either extreme adaptability or language learning being quite decoupled from vision and hearing. From an evolutionary standpoint, I imagine that both deafness and blindness are probably uncommon enough that language learning could have explicit dependencies on both hearing and vision.

I found an old-looking video about communication with deafblind people. At the linked timestamp is a woman who is deafblind since age 2.

https://youtu.be/usaf3bVVvjY?t=840

[0]: http://www.nightshadebooks.com/Downloads/Exhalation%20-%20Te...

https://en.wikipedia.org/wiki/List_of_vehicle_speed_records

I think this claim deserves a justification. Not saying you're wrong but I'm interested in how to compare browser security.

(Counteranecdote: the HN-popular article [0] which explained the Firefox zero-day, mentioned in it's last paragraph a Chrome zero-day from March 2019.)

[0] https://www.zdnet.com/article/mozilla-patches-firefox-zero-d...