I now commited your files (with several changes).
Martin Baker wrote:
>
> I don't think the DeltaComplex to SimplicialComplex coercion is crucial
> so if you are not happy with it then it could be omitted.
ATM I keep it, but modified so that it should now work on
DeltaComplex obtained from SimplicialComplex, but it is
likely to fail for other DeltaComplex-es.
Normally such functions in FriCAS are called 'retract'.
Since retraction may fail normally there is a pair
'retract/retractIfCan' with the second returning a union.
> I read somewhere, probably Hatcher, that SimplicialComplex and
> DeltaComplex are not isomorphic but that DeltaComplex is very marginally
> more general. However I get the impression that, in most cases, there is
> a triangulation in a higher dimension that does not repeat node and
> edges in this way. I have not come across an algorithm to do this and
> the approach that you suggest looks very interesting.
Well, first _you_ need define things. Delta complexes in Hatcher
are clearly different from your DeltaComplex. For example
Delta complexes in Hatcher may be used to represent cubical
complex only after triangulation of cubes, while you map
cubes directly to cells of your complex. To get something
close to Hatcher's definition you would have to require that
boundary of n-dimensional cell for n>0 has exactly n + 1
pieces. To be able to reconstruct maps present in Hatcher's
definition you would have to give extra information, for
example correspondence between vertices of boundary of
n-dimensional simplex with vertices of n - 1 dimensional
simplices. That is instead of merely giving orientation
you would have to give permutation.
After such change your complexes would agree with Hatcher's
book, but you would loose large part of current capabilities.
Also, there would be a lot of redundancy in representation
meaning that for example hand preparing of data would
take more effort. And there would be need to check that
all that redundant informations agree.
In bugs2016.input I included a bunch of tests. One example
is father fishy and it is not clear if we want to declare
it a legal delta complex. But even this fishy example
produces sensible output. There is representation of
circle as delta complex showing that it is more economical
than simplicial complex (AFAIK this is Hatcher's delta
complex). There are examples of tori, 2 and 3 dimensional
ones: they are somewhat like cubical complexes, but
taking advantage of possibility to alias parts of
boundary. AFAICS thay are _much_ smaller than anything
which satisfies restrictions of simplicial complex.
Concerning converting delta complexes to simplicial
complexes: AFAICS Hatcher's delta complexes can be
converted via subdivision. But IMO coding such
convertion would be of little use.
> It seems to me that algebraic topology is a big area of mathematics and
> requires a lot of code. Is it realistic for it to appear, fully formed,
> in FriCAS in one step? I would really help me to get the basics in
> FriCAS which would give me the confidence to spend more time on the details.
Well, I am not talking about doing things in one step. But
it is good to get some basic parts right so that one can
base future code on them. ATM I think that VertexSet
is messed up. Let me present a simple example, namely
simplicial complex with 3 vertices (say 1, 2, 3) and
a single edge (say between 1 and 2). Now, vertex 3
in not connected to anything but is still part of the
complex. So we need to specify somewhere set of
vertices of the complex. Currenly it is done via
vertex set part in representation of complexes. But
this clearly is highly suboptimal. In particular
your VertexSetAbstract can only represent intervals
so it is not possible to perform simple operations
like renumber vertices keeping 1 in place and mapping
2 to 4 and 3 to 5 without introducing extra nodes.
So it would be better to keep list of nodes in the
complex. But then your VertexSet is not needed at
all: you may want domain for vertices but there is
no need to specify _subset_ of domain.
Concerning changes that I made: there are global
changes like using 4-space indentation, adding
whitespace around operators, breaking overlong
lines which help reading the code. I removed
a lot of coercions from Strings to Symbol:
when string is used only for printing efficiency
of strings and symbols is comparable, but whithout
coerce source code is simpler and more readable.
Also changed most of occurences of 'empty()$List...'
by '[]$List...' and removed some unnecessary
declarations.
In DeltaComplex there was an attempt to keep vertices
in representaion, I removed it. It does not mean
that I am against keeping vertices there: simply
there were several errors and dropping this part
looked like easiest way to get working code.
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.
Concerning vertices: simple solution
is to have domain parameter giving types of
vertices. All what is needed for basic algorithms
is equality and a way to print them (that is
SetCategory). Instead of your VertexSetAbstract
one would simply use NNI. For geometric complexex
one could use Vector(Integer) (or Vector(S) with
some more capable S like expression).
--
Waldek Hebisch
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
