On 30/08/16 16:43, Waldek Hebisch wrote:
Concening future developement, we need to rethink
some basics. First, current DeltaComplex looks
fine for homology (except for lack of vertices in
representation). But it is underspecified for
homotopy. As I wrote, there should be enough
information to compute fundamental group, but
not enough for higher homotopy. And even
fundamental group seem to give wrong results
sometimes. So one way to go forward is
to declare that DeltaComplex is only for
homolgy (and by extension cohomology).
Alternatively one may work out how to represent
maps, say piecewise linear map and use this
representation in DeltaComplex. At some
moment we will like to represent maps anyway
(they are needed for functorial properties and
for higher homotopy), so IMO resonable way
is to say that just now DeltaComplex is for
homology (and maybe fundamental group) and
implement similar but more topological domain
later.
To help analyse this, I think torus shows the issues most clearly.
First the fundamental group when we start with SimplicialComplex:
(1) -> tS := torusSurface()$SimplicialComplexFactory
(1)
(1,2,3)
(2,3,5)
(2,4,5)
(2,4,7)
(1,2,6)
(2,6,7)
(3,4,6)
(3,5,6)
(3,4,7)
(1,3,7)
(1,4,5)
(1,4,6)
(5,6,7)
(1,5,7)
Type: FiniteSimplicialComplex(VertexSetAbstract)
(2) -> fundamentalGroup(tS)
(2) <o t w | o*w*t, o*t*w>
Type: GroupPresentation
I think this can be further simplified, I suspect that it will take a
long time until the simplification gets to the level of the GAP program
for example. We could re write the above as:
<o t w | -o = w*t, -o = t*w>
Substituting for -o we have:
w*t = t*w
That is, two edges that commute.
Moving everything to one side of the equation we have:
t * w * -t * -w
Now lets look at the situation for the compacted form
(3) -> tD := torusSurface()$DeltaComplexFactory
(3)
1D:[[1,- 1],[1,- 1]]
2D:[[1,2,- 1,- 2]]
Type: DeltaComplex(VertexSetAbstract)
(4) -> fundamentalGroup(tD)
(4) <b c | b*c*b*c>
Type: GroupPresentation
This is not correct, we have lost the orientation information, so how
does this happen? The fundamental group is all about loops and the
algorithm works by finding loops, each loop will be an edge not in the
spanning tree:
(5) -> uG := UndirectedGraph(NNI)
(5) UndirectedGraph(NonNegativeInteger)
Type: Type
(6) -> grapht : uG := oneSkeleton(tD)
(6)
Vertices: 1
Edges: 1-1,1-1,1-1,1-1
Type: UndirectedGraph(NonNegativeInteger)
(7) -> spant : Tree(Integer) := spanningTreeNode(grapht, 1::NNI)$uG
(7) 1
Type: Tree(Integer)
But this is not necessary, because we only have one vertex, we already
know the loops, every edge is a loop. So we don't need to do this
spanning tree stuff.
In fact the information we want is already in the DeltaComplex
representation in its purest form:
2D:[[1,2,- 1,- 2]]
Representing the edges by 'A' and 'B' we get:
A * B * -A * -B
So we can calculate the fundamental group:
1) In the case of a fully triangulated DeltaComplex from the mapping
from 1D to 0D cells (the graph).
2) In the case where it has been reduced down to 1 vertex, we then use
the mapping from 2D to 1D cells.
But what about the situation inbetween these two extremes? Somehow I
think we need to use both mappings.
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
