pi-base / data Goto Github PK

Right now the pi-base viewer supports three kinds of references:

• DOI (doi:)
• Mathematical Reviews (mr:)
• Wikipedia (wikipedia:)

We've started to use the following references, and the viewer will eventually display them:

• Math.StackExchange (mathse:)
• Math Overview (mo:)

What other references should we support? We've avoided supporting generic URLs historically to emphasize that we want things subject to some sort of peer review. But @prabau suggests that some JSTOR references don't have DOIs or MR numbers. Do we add JSTOR? Or is there another broad tagging mechanism like DOI/MR that would cover that use case?

https://topology.pi-base.org/theorems/if490b8d8-26a3-4d43-b846-bef71e6b2440

https://topology.pi-base.org/theorems/i8ef66fa2-f047-4355-981c-d6e5d7ea4ef0

I'm currently unable to ssh into the server so I cannot fix this right now.

Just a test for Chris...

It seems that in various types of references the "name" attribute is not displayed on the web pages.

For "doi" refs, the "name" is used and displayed properly. Example:

• https://topology.jdabbs.com/properties/P000003/references (correctly shows "Counterexamples in Topology")

The other types of refs don't display the name at all. "mr" and "wikipedia" refs at least have a default display format that allows to click, but I would think the intent was to display the name. Examples:

• https://topology.jdabbs.com/properties/P000011/references (not showing "General Topology (Willard)")

But for "mathse" refs, there is not even a default, so nothing is displayed and there is nothing to click to access the reference. Example:

• https://topology.jdabbs.com/theorems/T000246/references

I was wondering why the Odd-even topology (product of discrete countable by two points indiscrete) was showing as not being perfectly normal:
https://topology.jdabbs.com/spaces/S000005/properties/P000015

It is not T6, as it is not even T0, but it should be perfectly normal, as far as I can tell.
The reason seems to be the combination of these two theorems:
T180: Perfectly normal implies cozero complemented
T126: Cozero complemented implies T3.5

The article mentioned in the reference for cozero complemented (https://topology.jdabbs.com/properties/P000061/references), as well as https://www.sciencedirect.com/science/article/pii/S0166864103003766 only mention that notion in the context of Tychonoff spaces. I assume that's why the definition assumes T3.5.

So it seems we need to change T180 to "T6 implies cozero complemented".
Would you agree?

https://topology.jdabbs.com/spaces/S000126/properties/P000048

As mentioned on that page, this is shown in Steen & Seebach item 3 for space 129, and I can understand the argument in the book.

But I cannot make sense of the alternative argument in pi-base. Assuming U_p and U_q are disjoint (not mentioned, but I assume that's the case). The boundary of U_p must intersect L(c). So far so good. But why does that imply the existence of t in C such that $\delta U_p \cap L(t) \cap X$ is nonempty? (for example it could be that a point in L(c) intersect boundary of U_p is an isolated point of the boundary of U_p that does not even belong to X, and there are no nearby points in the triple intersection above.)

Furthermore, the argument in the book makes essential use of the fact that Cantor's leaky tent (i.e. with the apex added back) is connected, which is a highly nontrivial result. But the alternative argument above makes no use of that fact. It seems it would be too simple to work.

Maybe I am missing something simple. Do you guys think the alternative argument works?

All spaces need to be labeled as trivial:false by definition except the indiscrete spaces which are trivial by definition.

Where possible, it'd be nice to have our UIDs match Counterexamples in Topology. This won't be completely possible, as some counterexamples are somewhat loosely defined (e.g. we will need to tighten one-point compactification of an uncountable discrete space to be of cardinality omega_1). But it's a nice gesture.

(original issue was much broader but now only asks to do this:)

Can we easily change I###### to T###### for theorems?

It's not unreasonable to want to store information on traits that haven't yet been decided. For example, I might have a preliminary result that S123456 has property Q, but it hasn't yet been peer-reviewed. It makes sense to add this information to the pi-Base for reference, but not mark its value one way or another (since the trait hasn't been peer-reviewed).

A lot of what I'm working with these days boils down to theorems of the form:

The following are equivalent.

• X has property P.
• C_p(X) has property Q.

We have plenty to do as-is, but I want to make sure we put C_p theory on the roadmap somewhere.

The deductions for properties of certain spaces seem unnecessarily complicated when making use of theorems of the form (A implies (B and C)), i.e., when the the conclusion of the theorem consists of the conjunction of more than one property.

For example there is https://topology.pi-base.org/theorems/T000125 (Second countable implies Lindelof + first countable + separable). Look at how this is used to show that the Single ultrafilter topology is not second countable: https://topology.pi-base.org/spaces/S000111/properties/P000027. The result should be a one liner, but there are four theorems listed to justify it.

Or another example: the Discrete topology on the real numbers is not second countable: https://topology.pi-base.org/spaces/S000003/properties/P000027. Eight theorems are listed for that justification, where four would be enough!

This seems to be a limitation of the inference engine of pi-base. We have a theorem of the form (A ==> B + C + D). It would be enough to make use of (A ==> B) for example. But pi-base tries to relate all other possible properties involving C and D even when not necessary for the proof at hand.

In order to avoid these complications I would like to suggest to split such theorem into separate ones (A ==> B), (A ==> C), etc. This should hopefully simplify things. Would one of you be able to try to split T125 as a proof of concept and see what the result becomes for the two properties mentioned in the examples above?

Right now the UID is shown in both the filename and the metadata. Pi-base yells if these don't match, but do we really need it both places?

This suggestion came in through email

I was looking at the definition of “locally compact” property at $\pi$-base. In my version of Willard’s “General Topology”:

18.1 Definition. A space $X$ is locally compact iff each point in $X$ has a nhood base consisting of compact sets.

And the current $\pi$-base definition is

A space $X$ is locally compact if each point of $X$ has a compact neighbourhood.
These definitions match for Hausdorff spaces, but not even for locally Hausdorff ones! See

https://math.stackexchange.com/a/337657/58818

The $\pi$-base definition coincides with Munkres’ (Sec 29), Kelley (p. 146), and Counterexamples’, though... But Willard’s definition seems overall more in vogue nowadays at least for Operator Algebras.

It's worth considering if this is a point where we want to make another break with counterexamples sim. the T_ns, or just want to add another property (and maybe links between them).

Theorem: hemicompact + first countable implies weakly locally compact

Source: Henno Brandsma (https://math.stackexchange.com/users/4280/henno-brandsma), A first countable hemicompact space is locally compact, URL (version: 2018-09-16): https://math.stackexchange.com/q/2919068

See #201

I was wondering why pi-base was claiming that the Empty space was not meager: https://topology.pi-base.org/spaces/S000163/properties/P000056. It's because of T134 (Baire implies not meager). That result is generally true, except when the space is empty.

So we could fix this by introducing "empty" as a property. Would not be too onerous to do, as it would be implied by "has distinct points", and we would just add explicit traits for the Empty space and the Singleton. Does that sound reasonable?

https://math.stackexchange.com/q/4597483

I don't have time to write this issue up now, but I'm posting this placeholder to remind me to get back to this.

Here's a proposed workflow for contributions. Once it's decided on, we should have this in CONTRIBUTING.md.

1. New contributions are made via pull request.
2. James's custom CI tool (is this on GitHub?) automatically makes the following guarantees:
   • no duplicated stubs
   • no contradictions
   • citations in every file
   • Others?
3. If the PR passes the above checks, an Editor (right now just Steven) verifies that the contribution is supported by its citations
4. Once approved by the editor (through what mechanism?), the CI tool makes the following enhancements:
   • builds appropriate UIDs
   • others?
5. CI tool merges new contribution to master and delivers updated database to jamesdabbs/pi-base-viewer

We should adopt internal linking, e.g. {{pi-base:S123456}} links to space S123456. This would be particularly useful when discussing properties, since property P123456 might have a half-dozen different names in the literature and we are IDing these things for exactly that purpose.

Another project for a student I think...

I'm working on the audit branch to make sure that everything with the urysohn slug matches the use of "Urysohn" in counterexamples. However, I've renamed the urysohn slug to say "Completely Hausdorff" as in Willard. So when slugs are dropped, the canonical name for separating points by a continuous map into the interval will be "Completely Hausdorff". Note that this property is not implied by T_3 (not all points/closed sets can be separated by continuous real maps without T_{3.5}), so it is not a T-axiom.

Meanwhile, separating two points by closed neighborhoods will be associated with the current t_{2-frac{1}{2}} slug, as it fits between T_2 and T_3, although this property is called "completely Hausdorff" in Counterexamples and "Urysohn" by Willard.

See https://en.wikipedia.org/wiki/Urysohn_and_completely_Hausdorff_spaces for an explanation of the confusion.

This refers to spaces for which converging sequences have a unique limit (https://topology.jdabbs.com/properties/P000099).

Would it be possible to make "US" the name of the property and make "Sequentially Hausdorff" the alias instead?

The terminology "US space" seems a lot more common than "sequentially Hausdorff space". A search in mathoverflow does not show a single example of "sequentially hausdorff", and shows several with "US space". mathstackexchange has only one page mentioning "sequentially Hausdorff" in passing, as a synonym for US, and several dozen pages for US. Same thing when searching articles in Google (and even one article uses sequentially Hausdorff with a entirely unrelated meaning of separating points by sequentially open sets). Even the article used as reference in https://topology.jdabbs.com/properties/P000099 uses the US terminology.

The US terminology was introduced in https://www.jstor.org/stable/2316017 (Wilansky 1967).
Do you know where sequentially Hausdorff comes from?

We should add clarity on how the license applies to the data in this repo, and how it applies to contributions to this repo.

A P-space is a space for which every G_delta set is open (there's a lot of different concepts under the same name).
In this article https://www.sciencedirect.com/science/article/pii/0016660X72900268 on page 352, example 3.1 they provide two examples, both of Hausdorff non-regular P-spaces, one which is Urysohn, and another which isn't.
The article also contains other properties relating to P-spaces

As I work on #130, I'm seeing a bunch of redundancy blocking efficient contributions. The decision for each property having a file was based on the assumption each property needed a proof. But if we're relying more on peer-reviewed external sources, maybe this can be more conveniently contained in the yaml frontmatter of the space (in the PR I'm about to make, I just directly cite MathOverflow for each property, and don't add any extra information).

The rational numbers are not hemicompact, and are thus an example of a space which is σ-compact, but not hemicompact. The database has no counterexample for this combination.

Source: Eric Wofsey (https://math.stackexchange.com/users/86856/eric-wofsey), A $\sigma$-compact but not hemicompact space?, URL (version: 2021-07-28): https://math.stackexchange.com/q/4209326

As noted in #56 we don't use them anymore, but they still appear in the repo (and might cause confusion). So unless we need them for legacy reasons we should remove them.

An extension of #74 -- it's a waste of space to say things like "A space X is compact if for every open cover of X there exists..." when we could get to the point: "For every cover of the space X there exists...". This also has the advantage of removing the reference to a canonical name for the space/property, which may change later. (Though we still eventually need support for e.g. {P123} to display the current canonical name for property 123.)

It seems like the one-point space is a counterexample to some otherwise obvious implications (e.g. https://topology.jdabbs.com/theorems/I000088 says that a path connected space is not totally path disconnected, but the one-point space is both) due to vacuous quantification over pairs.

Excluding empty set as a topological space is acceptable for most math, but I don't think we can say the same about the one-point space.

I suggest adding the one-point space to the database, along with the property of having more than one point. I'm not sure whether it is better to assert the properties of the one-point space, or to add theorems deducing various properties from one-pointedness.

I cannot remember where we had this conversation @jamesdabbs but I seem to recall we thought about only supporting theorems of the form "If {set of properties} then Property" (where each property may be true/false). More complicated theorems may be captured using logic: e.g. "If P or Q then R" can be split into "If P then R" and "If Q then R".

Then there's no need for an and: in the YAML metadata, simplifying to something like:

uid: Taaaaaa
if:
  - Pxxxxxx
  - Pyyyyyy
then:
  Pzzzzzz
converse:
  - Txxxxxx
  - Tyyyyyy
refs:
  - [...]

Correct my logic but if we also add the requirement like that theorems with a single hypothesis always be "true", then we'd avoid duplicate theorems (e.g. no contrapositives)? (Duh P=>~Q and Q=>~P.)

Downside: Elegant characterizations like regular+2ndCount <=> separable+metrizable are hard to capture.

Aside: Did we document the appropriate YAML format somewhere?

The name Hjalmar Ekdal topology is rather obscure, especially since it came about as an inside joke (see https://proofwiki.org/wiki/Definition:Hjalmar_Ekdal_Topology).

I was wondering if it would be possible to change the primary name to "Countable sum of Sierpinski spaces". And at the same time add the anticompact property for example.

An artifact from when IDs were 1-1 with Steen/Seebach Counterexamples (which got messed up along the way anyway), S28 and S100 are duplicates (since they treated the irrationals and the Baire space as separate spaces). These should be merged as we only model topological properties up to homeomorphism.

Countable Hausdorff spaces with countably many continuous self-maps:
https://mathoverflow.net/questions/418619 https://mathstodon.xyz/@hartkp/109316149721859292

Hello, I was browsing the site when I noticed it said the countable box product of reals was a normal space (https://topology.pi-base.org/spaces/S000107/properties/P000013)

It struck me as odd for, as far as I knew, this hadn't been proven.
In fact, I found a math stackexchange answer which quotes from the 5th exercise, section 3.2, of Munkres' "Topology" as follows:

It is not known whether R^ω is normal in the box topology. Mary-Ellen Rudin has shown that the answer is affirmative if one assumes the continuum hypothesis [RM]. In fact, she shows it satisfies a stronger condition called paracompactness.

[RM] M. E. Rudin. The box product of countably many compact metric spaces. General Topology and Its Applications , 2:293-298, 1972.

Pi-base seems to have jumped to this conclusion based on the premise that it is T5 (https://topology.pi-base.org/spaces/S000107/properties/P000008).

In Pi-Base, it is coded that any perfectly normal space is $G_\delta$ space. This is not necessarily true for all non $T_1$ spaces.

One of the counterexamples is the right ordered reals found here this space is perfectly normal since there are no non-trivial disjoint closed sets. This space is not $G_\delta$ since any open set is of the form $(a, +\infty)$ and any closed set is of the form $(-\infty, a]$.

Right now the pi-base uses "Second category", a terribly non-semantic term. I prefer the usage found in modern literature: these are exactly spaces that aren't meager (countable union of nowhere dense sets). So, I'd like to scrub the "second category" property, flip all the booleans pointing to it, and point them to a "Meager" category instead.

See discussion at #143

https://topology.pi-base.org/properties/P000136 - compact subsets are finite

First we should add the alias "anticompact" used here: https://math.stackexchange.com/questions/517411/in-a-topological-space-only-finite-subsets-are-compact-sets

That source also suggests two theorems that will propagate the property in pi-base: every discrete space is p136, and T1 first countable p136 spaces are discrete.

We can also add every finite space is p136. I don't relish having finite spaces being both "compact" and "anticompact" so I don't suggest we change the canonical name for p136 in pi base, barring a lot of literature on the subject using the term I'm unfamiliar with.

I'll tackle this when I'm at a proper computer later this week.

See discussion in #55

/spaces/S000099/properties/P000008

Right now we just add a sentence at the end of the description specifying how the fact may be looked up in the references. I regret this; we would have more flexibility in how this information is presented if we had put it in the metadata. (Probably the job of a student worker...)

We usually try to eliminate redundancies in pi-base, but sometimes it helps to organize things to have a separate name for a related combined property (T3 vs. regular, T4 vs. normal, etc). I think it would be beneficial to add "locally compact Hausdorff" (LCH) as a property. They are many locally compact variants, but they all coincide in the Hausdorff case. Also many theorems involve the combination "weakly locally compact + T2" (see https://topology.pi-base.org/properties/P000023) and could be simplified accordingly. Comments?

• Willard 3.A.4
• This is NOT regular

Yesterday, answering the question "Example of an uncountable scattered space with some properties" on mathoverflow, Taras Banakh constructed an uncountable, first countable, Hausdorff, Lindelöf scattered space. I believe this must necessarily be on the π-base!

I assert the first implication in a comment here https://math.stackexchange.com/questions/3844039/what-topological-properties-are-trivially-vacuously-satisfied-by-any-indiscrete/3844184#comment7929993_3844050 but want a sanity check before I add it to the community answer and then pi-Base. The 2nd implication also seems valid but could use some more thought.

In general we have nothing on https://topology.pi-base.org/properties/P000121 so these theorems would help, and would generalize https://topology.pi-base.org/theorems/T000029

(Second countable + Sequentially compact) implies Compact.
This is confirmed by doing a space search for "Second Countable+Sequentially Compact+~Compact" and getting a response that it's impossible because:

• T000125: Second countable implies Lindelof + First countable + Separable
• T000003: Sequentially compact implies Countably compact
• T000106: Lindelof + Countably compact implies Compact

Therefore in T000060 (Sequentially compact + Second countable + T1 implies Compact) the T1 hypothesis is superfluous, and since T000060 can then be derived from the other theorems, it does not serve much purpose and I propose to remove it.

Please let me know if you agree.