lifepillar

I attended one of his talks (but not the ones you mention), during which he described how he was approaching the topic. He said he was reading the most important papers on sat problems in chronological order, and implementing each of the algorithms he found along the way. At the time of the talk, he was half-way through the ‘80s, IIRC.

A lesson in commitment and perseverance for me. And a very funny talk as well (Knuth likes jokes!)

The most important property of surrogates, which I never see mentioned, is that two tuples, anywhere in the database, have the same surrogate key if and only if they are (believed) to refer to the same real-world entity. This is a crucial difference wrt auto-incrementing or randomly generated values that are independent in different relations (which is a common practice). Among the rest, with surrogates defined as above you may freely join relations on surrogate keys being sure that you are joining related data.

In his landmark 1979’s paper, Codd defined surrogates and pretty clearly, and that part of his work was based on an earlier paper entitled On Entities and Relations (I don’t recall the authors right now), so this is not exactly news.

Unfortunately, current DBMSs provide little to no support for properly implemented surrogates.

If you assume that NULL is a placeholder for a value that exists, you must require the basic property that A=A be true, even when A is NULL, because any value equals itself. This does not mean that NULL=NULL should always be true. So, this is just to point out one of the many examples of SQL being incompatible with a "value existent, but unknown" semantics. NULLs in SQL are quite a mess.

K3 has no tautologies, but Ł3 does have tautologies, e.g. P->P.

However you interpret a NULL (as "value existent but unknown", "value not existent", or "no information, i.e., value might exist or not"), you will have a hard time matching your interpretation with SQL's behaviour, no matter what the standard says. In fact, interpreting NULLs as "value existent but unknown" is the most troublesome of the three interpretations, both because of SQL's rules (for instance, select * from T where A=A is empty if A is NULL, but an existent value should be certainly equal to itself even if you don't know what it is) and due to the intrinsic computational complexity of related problems (basically, related to the intractability of recognising tautologies).

The closest to a sensible semantics that I have seen is a 2012's paper titled "On the Logic of SQL Nulls", which argues that the "correct" interpretation of NULL is "value not existent". It is a quite theoretical paper, though, and it covers only a subset of SQL.

If you want to use NULLs meaning "value exists but is unknown" I recommend that you the papers written by Hans-Joachim Klein, mostly in the '90s. His "switching semantics" provides some very interesting rules for writing queries with NULLs, which are at least guaranteed to output a subset of the correct answers wrt some reasonable definition of "correctness" (some of his results were rediscovered recently by Libkin btw).

Surely there are minimal subsets of functionally complete operators, in general different ones for different three-valued logics. E.g., for Łukasiewicz's logic (L3), ∧ (conjunction) and ⟶ (implication) will do (implication is not definable using other operators).

I doubt that you could define, L3's operators just with NAND (or NOR). In L3, "N implies N" is T, and "not N" is N (where N is the third truth value). So, in one case, a formula whose components are all evaluated with N has truth value T, and in the other has truth value N. This is not a proof, of course, but I'd like to see such a definition of NAND :)

Interestingly enough, with F571 SQL's propositional fragment is functionally complete: any three-valued truth table can be defined. For instance, Łukasiewicz's P ⟶ Q can be expressed with

    (not P or Q) or (P is unknown and Q is unknown)

and the Słupecki operator, which is needed to obtain a functional complete system from L3, can be expressed with:

    (P or unknown) and unknown

It sounds like something really innovative for those times. Do you know more about that system? Is there a disk image anywhere?

You may ask this guy: https://github.com/nicolaprezza

He already has some interesting code :)

I had something like that in my vimrc for some time (snippet posted here: https://vimrcfu.com/snippet/222), using omni-completion when set in the buffer and keyword completion otherwise. Then, I developed the idea into a plugin that retains the minimalistic spirit, but it's much more flexible: https://github.com/lifepillar/vim-mucomplete.

Some time ago, Apple launched a recall program for defective power adapters:

http://www.apple.com/support/ac-wallplug-adapter/

I had the problem mentioned in the subject. Replacing the plug adapter has fixed it.

Here's the talk: https://www.youtube.com/watch?v=0LR_lBEy7qU

You may be interested in PLASMA:

https://github.com/dschmenk/PLASMA