coq-community / topology Goto Github PK
View Code? Open in Web Editor NEWGeneral topology in Coq [maintainers=@amiloradovsky,@Columbus240,@stop-cran]
License: Other
General topology in Coq [maintainers=@amiloradovsky,@Columbus240,@stop-cran]
License: Other
The newer coq versions give some compilation warnings about how some hints are defined. (fragile-hint-constr)
Look into that and either disable the warning or follow the recommendation of the warning (declare constants for the hints).
I have cloned topology
and zorns-lemma
, renamed the zorns-lemma
directory to ZornsLemma
and made it a sibling of topology
.
The README states The library depends on my ZornsLemma contribution. The provided makefile expects compiled files to be present in ../ZornsLemma
. This condition is met, but I still get the error:
Cannot find a physical path bound to logical path matching suffix <> and prefix ZornsLemma.
Hi @stop-cran, long time no see.
Thanks for fixing the build warnings in your recent commits. (b46b4cd, 19de219, edbbddc)
A lot of the changes are only changing the line endings and back again, which clutters git blame
.
Do you mind if I squash these three commits into a single one and force-push it to master
?
This would keep the repo tidier.
I want to create a very simple topological space on X={a,b,c}
with the open sets T={{b},{b,c},{a,b},X,∅}
, but I'm having great difficulty in doing so (code below). In particular, I'm stuck on this goal (see the location of admit
in the code):
1 subgoal (ID 70)
F : Family X
HF : forall S : Ensemble X, In F S -> T S
============================
T (FamilyUnion F)
also, is there a way to perform reflection on Ensembles to discharge the easy proof about being closed under finite intersections?
From Topology Require Import TopologicalSpaces.
Require Import Ensembles.
Section TopSpaceEx1.
Inductive X : Type := a | b | c.
From ZornsLemma Require Export EnsemblesImplicit.
Definition T (x : Ensemble X) : Prop := Same_set x (Singleton b)
\/ Same_set x (Couple b c)
\/ Same_set x (Couple a b)
\/ Same_set x Full_set.
Ltac destruct_ensembles_in :=
match goal with
| [H : Ensembles.In _ _ |- _] => destruct H
end.
Ltac destruct_ensembles :=
split; red; intros;
repeat destruct_ensembles_in.
Ltac inversion_ensembles_in :=
match goal with
| [H : Ensembles.In _ _ |- _] => inversion H; clear H
end.
Ltac ensembles_inv :=
let x := fresh "x" in
let H := fresh "H" in
split; red; intros x H; destruct x;
repeat inversion_ensembles_in.
Lemma T_is_topology : TopologicalSpace.
Proof with auto with sets.
refine (Build_TopologicalSpace X T _ _ ltac:(firstorder)).
- intros F HF.
admit.
- intros.
destruct H as [? | [? | [? | ?]]];
destruct H0 as [? | [? | [? | ?]]];
apply Extensionality_Ensembles in H;
apply Extensionality_Ensembles in H0; subst; unfold T.
+ left...
+ left; repeat destruct_ensembles; constructor.
+ left; repeat destruct_ensembles; constructor.
+ left; repeat destruct_ensembles; constructor.
+ left; repeat destruct_ensembles; constructor.
+ right; left; repeat destruct_ensembles; constructor.
+ left; ensembles_inv...
+ right; left; repeat destruct_ensembles; constructor.
+ left; repeat destruct_ensembles; constructor.
+ left; ensembles_inv...
+ right; right; left...
+ right; right; left; repeat destruct_ensembles; constructor.
+ left; red; repeat destruct_ensembles; constructor.
+ right; left; repeat destruct_ensembles; constructor.
+ right; right; left; repeat destruct_ensembles; constructor.
+ right; right; right...
Admitted.
End TopSpaceEx1.
Is it possible (and easy to use) to create a coercion from Ensemble X
to TopologicalSpace
via @SubspaceTopology X
, where X : TopologicalSpace
?
This would be useful, because it allows some things to be stated more concisely (and is often done in mathematical practice). For example the notions "compact subset" or "connected subset" of a space would be automatically clear and wouldn't need to be defined separately.
The code
Coercion SubspaceTopology : Ensemble >-> TopologicalSpace.
Produces the warning SubspaceTopology does not respect the uniform inheritance condition [uniform-inheritance,typechecker]
and Coq still says that SubspaceTopology is now a coercion
.
But still, the following does not work:
From Topology Require Import SubspaceTopology Connectedness.
Coercion SubspaceTopology : Ensemble >-> TopologicalSpace.
Section S.
Variable X : TopologicalSpace.
Variable U : Ensemble X.
Fail Variable V : Ensemble U.
Fail Variable p : U.
Fail Variable f : U -> X.
Fail Goal connected U.
End Section S.
These basics would be necessary to simplify work with subspaces.
I’d like to add some examples of (pathological) topological spaces to the library. For the long line I need the following:
ω_1
.I’m currently struggling with the definition of ω_1
. Wikipedia gives Hartog numbers as slight hint. But my problem is not conceptual, in understanding the mathematics, but in the formalisation in Coq.
I’d like to use the Ordinal
and well_founded
definitions from Ordinals.v and WellOrders.v, but well_founded
demands forall a b, a < b \/ a = b \/ a > b
, while we can only prove forall a b : Ordinal, a < b \/ a == b \/ a > b
. So the theorems of WellOrders.v remain unavailable for the Ordinal
type. Interestingly, ==
isn’t extensional for Ordinal
; for it is possible to prove ~ forall a b : Ordinal, a == b -> a = b
.
I see three possible ways to continue:
Ordinal
type, so a == b -> a = b
holds. That actually looks rather difficult, since we can’t easily take quotients. Maybe Induction-Induction would lead to a suitable definition, but currently that needs axioms, which isn’t very satisfying.well_founded
definition (specifically total_strict_order
) so it is only up-to-equivalence. I.e. use Setoids. But since the rest of the library avoids using Setoids, I don’t want to introduce them here.Ordinal
type, on the type of well_founded
relations. Using a bundled structure (i.e. a Record WF_Type := { carrier : T; R : relation T; wf : well_founded R }.
) might simplify the work, because always carrying T
and R
around is a bit annoying. It would be necessary to show that WF_Type
is itself a well_founded type, then we could (probably) carry out the construction of ω_1
. And the layered universes will probably make sure that no paradox arises.We might want to add more theory about ordinals, like ordinal arithmetic. But hopefully with an ordinal type where a <= b -> a => b -> a = b
.
P.S.: The proof that ==
is not extensional. We might want to add this to the library, as a reminder that ==
isn’t nice enough. The trick of the proof is to notice, that ord_sup
isn’t injective with respect to ==
. The term ord_sup (fun H:False => match H return Ordinal with end)
corresponds to the ordinal zero.
Lemma ord_eq_not_extensional :
~ forall a b : Ordinal, a == b -> a = b.
Proof.
intro.
pose (a := (ord_sup (fun H:False => match H return Ordinal with end))).
pose (b := (ord_sup (fun _:True=> (ord_sup (fun H:False => match H return Ordinal with end))))).
assert (a == b).
{ unfold a, b.
repeat constructor; intros; contradiction.
}
specialize (H a b H0).
unfold a, b in *.
inversion H.
pose proof I.
destruct H2.
assumption.
Qed.
Maybe it'd be useful to give some simple and practical examples to the defined topological constructions and proven theorems. E. g. a homeomorphism between a unit interval with identified ends and a unit circle.
There are multiple ways to characterize RTop and its subspaces (up to homeomorphism) based on order or metric properties. Such theorems could help transport topological properties.
IIRC the following statements are true:
Rle
on a closed interval.x => a*x+b
for a<>0
is an automorphism of RTop andI'm sure there's some way to use the metric structure, but haven't yet looked into a precise statement. Metrically complete and separable are probably important again.
Small conjecture: an order topology is separable/second-countable iff there's a countable dense subset. A subset A of an ordered set X shall be called dense if for all x, y : X
with x <= y
there exists a : A
such that x <= a <= y
.
An n-dimensional manifold M is a second countable Hausdorff space that is locally homeomorphic to Rⁿ . There seems to be several parts in the library already:
second_countable
Hausdorff
homeomorphic
The "locally homeomorphic" part requires that every point p ∈ M there is an open neighborhood U ⊂ M and a homeomorphism x : U -> U'
for open U' ⊂ Rⁿ.
For smooth manifolds, the definition is a bit more involved and involves chart transformations and (Euclidean then topological) smoothness, which doesn't seem to be here yet.
To develop topology we need many facts from set theory. For this the zorns-lemma library was initially developed. There are currently quite a few lemmas about sets (i.e. Ensembles) in the topology library, that could as well go into zorns-lemma.
I think it’d be "cleaner" if the facts & tactics about logic & set-theory that don’t depend on topological notions were moved to zorns-lemma. EnsembleTactic.v, InverseImageLemmas.v and the finite_indexed_union
in SumTopology.v come to my mind.
If the current maintainers are ok with that, I’d copy the code mentioned above into zorns-lemma. I’d only remove the code here if the PR in zorns-lemma is accepted.
But this would only "fix" the current state. What if the topology library needs more set theory that hasn’t been developed yet in zorns-lemma? Every time we develop the new set-theoretic fact we would have to move it to zorns-lemma first, before we could commit the topologic fact depending on it...
I’m not yet sure about that. I think it would be a "nice" policy for this repo to have, but I’m not yet sure whether it is practical. What do you think?
Current code is somewhat hard to read. I'd suggest to create a coding style guide and amend all existing proofs to follow that style.
Below are my ideas about coding style to be discussed:
assert
tactic use curly braces to logically separate from other goals. Possibly with other bullets inside the assertion goal if needed. E.g.: ...
assert (forall a b:R, -b <= a -> a <= b -> Rabs a <= b).
{ intros.
unfold Rabs.
destruct Rcase_abs; lra. }
intros.
apply H.
...
...
destruct H.
apply H1. (* Fragile *)
...
destruct H as [? H1].
apply H1. (* Okay *)
...
Write a lemma in ZornsLemma of the form:
forall (X : Type) (fam : Family X),
In fam Full_set /\ (forall U V, In fam U -> In fam V -> In fam (Intersection U V)) <->
(forall (fin_fam : Family X), Included fin_fam fam -> Finite fin_fam -> In fam (FamilyIntersection fin_fam))
and one for union:
forall (X : Type) (fam : Family X),
In fam Empty_set /\ (forall U V, In fam U -> In fam V -> In fam (Union U V)) <->
(forall (fin_fam : Family X), Included fin_fam fam -> Finite fin_fam -> In fam (FamilyUnion fin_fam))
Applications for these lemmas arise/arose in the facts about filters and about open/closed sets. I already have these proofs, but I still need to rebase them.
I think, there’s some further generalization hiding in there... But that is probably not useful.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.