Nice job, Urs!

]]>Mike: I thought the “tongue-in-cheek” was about the suggestion to call it “Ore connection” instead. Sorry for misunderstanding.

Urs: I do agree that ’Galois’ isn’t very helpful. All in all, Ore didn’t do such a hot job here on nomenclature. :-)

]]>Sounds good to me

]]>I edited partition of unity to clarify around the case without point-finiteness.

]]>Oh well, that’s nice!, thank you. I might edit the entry in ‘partition of unity’ since it now reads ’in intuitionistic mathematics’ whereas the relevant definitions and proofs are already in BISH (constructive mathematics, without use of intuitionistic axioms).

{Many paragraphs in the thesis are marked with an asterisk * to indicate that they are valid in BISH}.

]]>Thanks for the pointer. I have added it here, here and here.

]]>If anyone is interested, there is a constructive (BISH) treatment of ’partition of unity’, ’locally finite open cover’, and ’star-finite open cover’ in section 3.1 of my thesis modern intuitionistic topology. It gives a simple proof that every per-enumerable* cover of a separable metric space has i) a star-finite refinement b) a subordinate partition of unity.

*A subset $U$ is enumerably open when it is an enumerable union of basic opens, a cover $\mathcal{U}$ is per-enumerable when it is an enumerable collection of enumerably open sets.

]]>something with a grandiose name like “Galois connection” was really just

In this case what bothers me is not that it is a grandiose term for a simplistic concept (that’s a problem for, say, “hyperdoctrine”) but that its reference to Galois theory is quite uninformative as to the nature of the concept.

]]>I have expanded the proof to be real careful about the argument for the continuity of the Urysohn function.

]]>Okay, thanks. We should says this more clearly in the entry then.

]]>I noticed that presently *topological basis* redirects to *basis in functional analysis* instead of to the entry *topological base*. This seems dangerous. I’d like to change that redirect.

Yes, it seems to be as I thought, from looking at the Google Books link, just before Lemma 2.6 in the Appendix.

]]>As I said, my tongue was in my cheek; sorry if I sounded too serious. (-: I agree with everything in #32.

It did somewhat annoy me when I first learned that something with a grandiose name like “Galois connection” was really just a (contravariant) adjunction between posets. I usually prefer to just say “adjunction” or “equivalence” even in the posetal case. I do think there is something interesting in the specific origin of such adjunctions between powersets by way of a relation between sets as in #10, and I’m more tempted to use the phrase “Galois connection” in that case (as in my paper with Moritz). If I was making any real point at all — which I doubt — it might be that I’d rather not have to learn to remember to distinguish between “Galois connection” and “Galois correspondence”; in the case of an equivalence I’d rather just say “equivalence”.

]]>added a proof to *Urysohn’s lemma*

Wrote out a proof for *paracompact Hausdorff spaces are normal*.

(By the way, I also looked at TopoSpaces here to check what they offer, and am a bit dubious about their step 5. But maybe I am misreading it. In any case, I feel there is a simpler way to state the proof.)

]]>I’ll just make one more comment on terminology.

why multiply terms needlessly for the same concept?

The context for my making that remark in the first place was wondering why Oystein Ore chose to give two names for the same concept *within the same article*. (At least, any subtle difference of meaning between them is undetectable to me.) That’s what I don’t understand.

It is practically inevitable that in the course of history, various names will be given to concepts by different people under different circumstances. The term “Galois connection” has long been established and people do use it (including me, and it seems Mike as well), and it wouldn’t be right for the nLab not to mention it and any nPOV insights that may be brought to bear, including the connection with adjunctions. Another example would be closure operator and monad. The concept of monad is more general than closure operator, and the exact same remark about “multiplying terms needlessly” would seem to apply there too – but then so would the point I’m making now, which is that the nLab has an important descriptive function to fulfill in surveying the language of mathematics. (And BTW I still do use the term “closure operator”.)

So I’m really not sure what the takeaway from Mike’s comments should be. We shouldn’t be saying “Galois connection” from now on?

]]>At *Separation axioms – reformulation in terms of topological closures* I have added statement and proof of T4 in terms of topological closures.

I have spelled out the proof at *paracompact Hausdorff spaces equivalently admit subordinate partitions of unity*.

This uses Urysohn’s lemma and the skrinking lemma, whose proofs are not yet spelled out on the $n$Lab.

]]>I have edited *support* to say that in topology the support of a function is usually to be the topological closure of the naive support.

I have added to the Idea-section of *Galois connection* some of these remarks. But one of you should expand further. Also, maybe further discussion of Galois connections as such should be had in its own thread.

I have added to *Galois connection* some more remarks to the Idea section, and expanded the Examples-section with the material that Todd wrote here.

Hmm, not sure. I’d have to check Dold’s book again. In principle one could say that one has a collection of functions to [0,1] such that at each point only countably many are nonzero, and the sum exists and is 1 at each point.

]]>28, 29: Pareigis uses at some places the notion of adjunction between a covariant and a contravariant functor, calling it “adjoint on the right” in one of the two imaginable cases. For example in his paper with Morris on formal schemes, proposition 1.1 doi pdf. I did not check if he has this notion in his category textbook.

]]>True. But we also have dual adjunctions.

]]>