Kurt and Waldek,
Thank you very much for your response, When I'm working in isolation I
tend to get in a rut so it really helps to get your perspective.
I need a bit longer to find the bugs and to look into the issues in more
detail but here are some initial comments.
* On
http://www.euclideanspace.com/prog/scratchpad/mycode/discrete/finiteGroup/presentation/
the sentence "Negative values indicate" ends abruptly,
I have competed it as follows:
Each relation is a list of indexes to generators. Negative values
indicate the inverse of the generator. So if '1' represents the
generator 'A' then '-1' represents its inverse 'A^-1'.
> so what's the
exact meaning|purpose of the '<|>'? Maybe I'm confused by the result of
fundamentalGroup(fillSquare).
This is the group with no generators and no relations. I assume this is
the trivial group as the identity element is sort-of assumed.
This is obviously a bug when it gives this value for square, I need to
debug the homotopy for cubical complexes.
* I also found some discrepancies regarding the following facts: a) any
convex subset has a trivial fundamental group and b) the first singular
homology group coincides (isom) with the abelianization of the
fundamental group (if path connected), e.g. a 'cube'. I might be
mistaken because I don't understand the group presentation yet.
Really its just a 'word' where each element can have an inverse and a
list of integers seemed like the most efficient representation. I would
be happy to choose a different representation. Perhaps I should do more
to hide this internal representation from the external interface?
* Do you intend implementing higher homotopy groups?
I would like to, but possibly not the highest priority? When I have
tackled the bugs I would like to move on to the cohomology issues you
mentioned below, I am also keen to support real (metric) geometries.
So far the main difficulty is not finding a valid fundamental group but
attempting to simplify it. Since there is no canonical form and no way
to know if there is a simpler form then this is more art than exact
algorithm. It will be very difficult to do this as well as GAP. I think
its the sort of thing where we just need to start with something that
works and the refine it over the years.
I don't know if this also applies to higher homotopy groups, I assume it
does?
Concerning 'homology' I find the algorithm quite elegant, however, why
do you define the function in each complex?
- FiniteSimplicialComplex
- FiniteCubicalComplex
- DeltaComplex
- ChainComplex()
For my taste it should be isolated as a general concept. Actually it
should be enough to define 'homology' on general abstract chains
represented as free abelian groups ([Z,Q,?]-Module whatever the
purpose). This would mean identifying simplices, cubes, faces, complexes
etc. with chains (not necessarily homogeneous).
Well to generate homology from FiniteSimplicialComplex or
FiniteCubicalComplex I first:
1) generate DeltaComplex from FiniteSimplicialComplex or
FiniteCubicalComplex
2) generate ChainComplex from DeltaComplex
3) generate homology from ChainComplex
So I have added homology functions to DeltaComplex,
FiniteSimplicialComplex and FiniteCubicalComplex just so end users can
avoid having to explicitly do these steps.
But I think this is not what you are saying. Are you saying there is
some, more direct method, which does not go through these steps?
I would like it if the Homology domain was an extension of existing
abelian group categories. Is there some way to do this that could handle
both infinite cycles and torsion?
What I really wanted to say is that it should be possible to achieve the
same functionality in about 300 lines of code. However, this is not so
important in the first place as to verify the algorithms.
There is a lot of junk in the code that is left over from debugging and
ideas that did not work out, I can tidy this up. But for more
fundamental changes I would need some help.
You mentioned 'cohomology' in your source code comments related to
DeRhamComplex (lines 43 and 2718): this is of course on another level
but if you base your package on chains then it might be useful for
DeRham homology/cohomology in simple cases. Why? Because we can identify
chains as DeRham currents which are acting on cochains ~ differential
forms (already in Fricas as DeRhamComplex). There are a lot of
difficulties of course working with R-Modules in Fricas, yet with the
CAD package it might be possible for some simple algebraic varieties.
I am keen to explore this area when the main bugs are sorted out.
I keep up testing.
I appreciate it, thanks,
Martin
--
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.
