housecarpenter

Writing my blog (https://thehousecarpenter.wordpress.com/) has helped me learn things because it provides me with a concrete motivation: instead of having the rather vague and amorphous goal of "learn about X", I can think of my goal as "learn enough about X to write a blog post about it". That's always been the idea behind having the blog, and it's worked decently for that purpose. It hasn't helped me at all with my career or with connecting with people, but that's unsurprising as I've never cared to optimize for those goals.

The reason sets are important is that they correspond to (Boolean-valued) properties. To each set, there corresponds the property of belonging to that set. To each property, there corresponds the set of all things with that property. I think this is the key reason why the relational algebra is a good foundation for a query language. When I'm writing a query, I'm thinking of some property P, such that I want the results of the query to be all records with property P. By utilizing the correspondence between properties and sets I can translate that property fairly directly into an expression in the relational algebra, and then the magic of a relational query language is that that expression is all I need to write to carry out the query. That's the sense in which relational query languages are declarative. I just write down the property of the results I want, and I get those results automatically without having to specify how to collect those results.

Having queries return multisets rather than sets "breaks" the relational algebra in the sense that it breaks this correspondence. Results of queries no longer correspond one-to-one to properties, since properties have no multiplicity. To be fair, you can identify the property being true or the element belonging to the set with having multiplicity > 0, and the property being false or the element not belonging to the set with having multiplicity 0, and by doing this you can think of SQL queries as corresponding to sets/properties most of the time. But if you're going to think of them that way, you might as well just have them be sets in the first place. The multisets are just a needless complication. Thinking about SQL queries in terms of multisets seems to only be compatible with a more imperative, non-relational approach to the language, where you still have to think algorithmically about how to assemble the collection of results that you want, rather than just directly characterizing the results in terms of a property.

What's sad about it?

I'm late replying to this, but---you need the axiom of choice once you have a family of non-empty sets rather than a single non-empty set.

At some point you have to go into the formalism to really understand it. It's really about an interchange of quantifiers. If you have a non-empty set X that it is true that

[a] (exists x)(x in X)

If you have a family F of non-empty sets X then it is true that

[b] (forall X in F)(exists x)(x in X)

But to say that you have a choice function f for F is to say that

[c] (exists f)(forall X in F)(f(X) in X)

It turns out that the laws of first-order predicate logic and the axioms of ZF set theory do not allow you to come up with a formal proof that [b] implies [c]. You can try to find one, and you will fail. It's like the parallel postulate in Euclidean geometry. There is actually a proof that the axiom of choice is not provable from the other axioms, but it's a pretty deep result. Historically, there was quite a long time between when the set-theoretical foundations for mathematics were developed at the start of the 20th century, which is when mathematicians realized that the axiom of choice was a principle that needed justification, and when Paul Cohen proved that the axiom of choice wasn't provable from the other axioms, in the 1960s.

So if you believe that the implication from [b] to [c] is self-evident, you have to assume

[d] (forall X in F)(exists x)(x in X) => (exists f)(forall X in F)(f(X) in X)

as an axiom, which is the axiom of choice.

I think most people are inclined to agree that [d] is self-evident---that's why it's generally accepted as an axiom, with only a minority of people objecting. However, in the larger context of set theory it makes a lot of sense to minimize the amount of existential assumptions we are making. Historically, set theorists assumed that any set given by a definable formula would exist, but this lead to contradictions (Russell's paradox). So there's some reasonable paranoia about using additional axioms when we don't need to, in case it somehow leads to another inconsistency.

I agree that infinity doesn't exist in the universe, but this isn't a problem for mathematics. Mathematics isn't about what exists in the universe, it's about what exists in the realm of concepts. Some concepts are more interesting than others, sure. Cantor's work made it clear that infinite sets are pretty interesting.

I don't think Jech is using "naturally" as in "natural choice"; he's just using it as a synonym for "obviously". If X is non-empty set then there exists an x in X, because that's what it means for X to be non-empty. The choice is arbitrary: if X is the set of all functions from R to R then you could take the exponential function, the x^2 function, etc., whatever you like; the point is that it is certainly possible to make some choice.

Doubting the axiom of choice means thinking that when you have infinitely many sets to choose from, it is possible that not only is there is no natural choice function, but there is no choice function at all.

It's true that any real number can be written with a finite number of symbols. In fact, I can write any real number x with exactly one symbol, namely x, if I define x to mean that particular real number.

Now if you fix a particular formal language for defining real numbers, with a finite alphabet, then the language only has countably many words, hence there are reals not definable in the language. But the notion of "definability" here is not independent of the choice of formal language.

So "choosing an undefinable real number" amounts to "choosing a real number not definable in L", where L is some fixed formal language---and this isn't particularly hard to imagine; given a specific L, you can probably quite concretely construct a real number not definable in L.

¬ is shift+` on the most common UK keyboard layout, but yeah, it would probably need to be popular in America.

I get your point that both of these are specialized notations/terminologies, but it's entirely possible for somebody to understand algorithmic complexity without knowing what "a rack, a host, a DC" is, there's no inherent connection between the two. As somebody whose interests tend to be more theoretical than practical, myself prior to reading the article would be an example.

I'm a long time user of EditPad Pro. I use Sublime Text and VS Code as well, but one thing I find EditPad Pro particularly good for is modifying the syntax highlighting schemes, or writing my own, which seems to be a more involved process in other editors.

Yeah, televised election debates weren't a thing in the UK until 2010.

They state that only as a disclaimer, after a bunch of other statements that hint at the opposite. Just adding a disclaimer to misleading writing merely makes it confusing and unclear for those who are paying attention, and still misleading for those who don't notice the disclaimer.

I think the writer might have been meaning to imply that there's a spectrum of properties from countably infinite to dense to uncountable, where each property is stronger than the previous one. But this is actually not the case. The Cantor set is uncountable, but nowhere dense. So density is not just something that's in between countability and uncountability---it's an orthogonal thing.

In the RDBMSes I'm aware of, you can disable foreign key checks while still adding the constraints themselves---they won't do anything as far as the DBMS is concerned, but can presumably still be picked up by whatever tool you are using to generate this link information.

It depends what you mean by "simplification". The fact that phonics is something that can be taught and can be helpful for learning to read indicates that English does have phonetic spelling rules, inconsistently applied as they may be. It would be possible for a spelling reform to preserve the existing spelling conventions of written English while simply making the rules more consistent. There aren't really that many outright ambiguities in written English. Sure, <a> can indicate a bunch of different sounds, but it's usually possible to tell what sound it is from the surrounding letters---e.g. it'll be "short" (as in <cat>) if it's in an orthographically closed syllable, and "long" (as in <name>) if it's in an orthographically open syllable. The trouble is that we have words like <give> and <many> which are straight-up exceptions to the usual rules about open vs. closed syllables (<many> also has an exceptional sound value for the <a>). Respelling these occasional exceptions (I'd go for <giv>, <menny>) might make English spelling considerably less confusing while still preserving its basic "look and feel".

There are languages like that---the distinction is referred to as "proximative" vs. "obviative". (Though strictly speaking, it differentiates between "more topical" and "less topical" third persons, which might not necessarily correspond with the order in which they're mentioned.) https://en.wikipedia.org/wiki/Obviative Apparently, there's even an Algonquian language which has a "further obviative" too, thus distinguishing three different levels of topicality.

But I don't get paid on a piece rate; the amount of time I spend working is constant. Anything that increases my productivity just means I get more work done. (Others may differ, but I know from experience that I like to keep to a fixed schedule.) And that's mostly benefitting my employer, not me, so it seems like something my employer should pay for, if they believe in it.

I'd be interested to hear why you think this, or if you can link to something that explains this perspective.

Since all three notions are closely interrelated, it's fairly trivial to take any one you choose as "fundamental" and define the others in terms of it:

- Sets as fundamental: define ordered pairs via Kuratowski's definition, define relations as sets of ordered pairs, define functions as relations not containing any two ordered pairs with the same first projection but different second projections

- Relations as fundamental: define sets as unary relations, define functions as relations the same way as before

- Functions as fundamental: define sets as functions where the codomain is some fixed singleton (characteristic functions are more appropriate for subsets of a set, rather than sets on their own), define relations as functions whose codomains are power sets

Because of this sort of thing, I don't think any notion of "fundamental" that's purely based on interdefinability really makes much sense.

I personally have a sense that some definitions are "constructive" and others are "destructive" (my use of "constructive" here is in no way related to "constructive" as in "constructive logic", it's just based on the English meaning of "construct"). Of the definitions I gave above, I perceive the definitions of functions and relations from sets, of functions from relations, and relations from functions as "constructive", while the definitions of sets from functions and from relations are "destructive". Since I can't think of any "constructive" definition of sets from functions or relations, while I can think of "constructive" definitions in the opposite direction, I would say sets are more fundamental than functions and relations. Whereas since both relations and functions can be "constructively" inter-defined, I'd say they're both on the same level.

Admittedly, I have no idea how to define "constructive".

Any species could prove the same theorems given the same axioms, but (besides the fact that they might not choose the same axioms) I'm not sure if they would prove the same subset of theorems that we have proven/will prove. Perhaps they'd have different ideas about what is interesting.

I am certainly not intending to intentionally spread FUD, though I guess you probably mean that I am unintentionally propagating FUD spread by other people.

All I mean by saying it's a "logical error" is that it's not an argument which is always valid. Of course particular instances can still be correct.

I think a definition of "proof by contradiction" which includes proof of negation is useful if you are reasoning classically (and this doesn't have to be something you always do, or always avoid; you can reason classically some of the time and intuitionistically some of the time). Although the ideal situation to avoid any confusion would be to have three separate terms, one covering both types of proof and two for the individual types.

You can define closed sets positively as well. A closed set is one which includes its whole boundary. An open set is one which excludes its whole boundary. Clearly then it is possible for a set to contain only part of its boundary, in which case it's neither closed nor open. Somewhat less obviously, it's possible for a set's boundary to be empty, in which case it is both closed and open.

You might be interested to know that in intuitionistic logic, you still have a one-sided contrapositive law, i.e. (A > B) > (~B > ~A):

  [1] A > B(assumption)
  [2] ~B (assumption)
  [3] A (assumption)
  [4] B (modus ponens on 1 and 3)
  [5] ~A (proof of negation on 3, 4 and 2)

It's only the converse that no longer holds. In general familiar equivalences from classical logic are still valid in intuitionistic logic but only in one direction.

The issue is that some people believe in intuitionistic logic, so to them, there's a difference between assuming something is true and deriving absurdity in order to prove its negation (which they think is perfectly fine, and which is what Euclid was doing), and assuming that its negation is false and deriving absurdity in order to prove that it's true (which they think is a logical error). They reserve the term "proof by contradiction" only for the latter type of proof, i.e. the one they think is not a valid type of proof. Whereas for believers in classical logic, to say that something is true is just to say that its negation is false, so they don't generally care about the distinction between these two types of proof---as far as they're concerned it's a valid proof, and a "proof by contradiction", either way.

I think when mathematicians call an operation denoted by juxtaposition a "product", that's usually because it's denoted by juxtaposition for some independent reason and they're drawing the syntactic analogy with the numerical product, and there isn't any deeper connection with multiplication than that. Independent reasons for using juxtaposition might include:

1. juxtaposition is shorter than any alternative and hence a natural choice for the most common / only operation on the set in question

2. the operation is roughly analogous to function composition, and when you apply two composed functions it looks like f(g(x)) with f and g juxtaposed (if the functions are among those that have the longest history of being written as prefix operators, e.g. sin, cos, log, you don't even need the paren between the f and the g)

3. juxtaposition is a natural way to express an operation which is just "putting stuff together", such as string concatenation

So while it makes sense to denote string concatenation by juxtaposition in mathematics, I think it's a bit of a leap to go from there to say that A * B is the right notation for a programming language. (Actually using juxtaposition would be fine, but a general-purpose programming language is likely to want to reserve juxtaposition for something else.)

Also if you run with the idea that string concatenation = putting two strings together, well, addition is sort of like putting two numbers together. Rephrasing that in mathematical language: natural numbers can be encoded as elements of the free monoid on one generator, in which case the monoid operation turns out to be addition. I think that might be why the A + B notation is preferred over A * B when we have to choose one or the other.

It's entirely possible to trust something to work one way (e.g. keep a trivially restorable backup of previous state) when you do one thing with it and not trust it to do the same thing when you do another thing with it (especially if it's something you do infrequently or have never done before). The advantage of cp compared to git is that it only does one thing (more or less), so you don't have the potential for "doing things you're unsure of" in the same way as git.

This may be somewhat off-topic, but I think the point of "you lose debug stack traces!" is that with tail call elimination, you have more possibility for confusion from people who inadvertently write a tail call, or who write something tail-recursive without caring about the stack growth (e.g. if it only recurses a few times in their use cases). That's where the increased difficulty comes from; of course loops/state machines/tail-recursive functions are hard to debug either way. I guess basically the problem is that with loops you know what you're in for with regards to debugging, whereas tail-recursion is kind of implicit---you have to learn how to recognize a tail call, which is non-trivial, or at least non-trivial compared to distinguishing a loop from a function call.

Python uses ARC plus a tracing GC for dealing with cycles, same as PHP: https://devguide.python.org/garbage_collector/

Perl uses ARC with no tracing GC, so you have to handle cycles yourself: https://www.perlmonks.org/?node_id=1173079

TCL uses ARC, and apparently doesn't need a tracing GC because it is impossible to create cycles in it: https://wiki.tcl-lang.org/page/Garbage+collection

& is also used for set intersection in Python. I think + for string concatenation isn't too bad, really. It fits in with the fact that length(s + t) = length(s) + length(t), the same way we write A × B for Cartesian product (since |A × B| = |A| × |B|, even though this operation is neither commutative nor associative) or B^A for a function space (since |B^A| = |B|^|A|).

It depends what you mean by tuple. In Python, tuples are basically just immutable lists. Just as lists with 1 element are useful, so are tuples with 1 element. You might be dealing with a tuple of unknown length, where the length could be 1. In other contexts, the word "tuple" often carries the connotation of "having a known fixed length", in which case the notion of a 1-tuple as distinct from the value itself is less useful.

I use it, personally. The other two options I find too aesthetically displeasing: not indenting the string looks bad when it's within an indented block of code, and using join and putting the strings in a list is just too much boilerplate. I will use """ if I don't care about the extra space put at the start of each line by the indentation.