Re: [fricas-devel] Algebraic Topology Issue 1
Martin Baker wrote: > > > As a face (part of simplical complex) (1,3) and > > (3, 1) are the same face. And problem is not due to wrong > > orientation of input: > > I remember now, it is the same face but we allow it to be included > multiple times in different orientations: > > (1) -> ASIMP := FiniteSimplicialComplex(VertexSetAbstract) > (1) FiniteSimplicialComplex(VertexSetAbstract) > Type: Type > (2) -> v2a:List(List(NNI)) := [[1,3],[1,3],[3,1]] > > (2) [[1,3],[1,3],[3,1]] > Type: List(List(NonNegativeInteger)) > (3) -> sc1 := simplicialComplex(vertexSeta(3::NNI),v2a)$ASIMP > > (3) > (1,3) > (1,3) > -(1,3) > Type: FiniteSimplicialComplex(VertexSetAbstract) > (4) -> addImpliedFaces(sc1) > > (4) [[-(1,3),(1,3),(1,3)]] > Type: List(List(OrientedFacet)) > (5) -> sc1::DeltaComplex(VertexSetAbstract) > > (5) >1D:[[1,- 2],[1,- 2],[- 1,2]] >Type: DeltaComplex(VertexSetAbstract) > > Under a strict geometric interpretation of a definition of > simplicialComplex I suspect that this should not be allowed? But, as we > discussed earlier, it is useful not to prevent this to allow > construction of interesting delta complexes. Well, in cases of simplicial complex this is an error: it may lead to wrong chain and maybe even to wrong homology. More precisely if we allow parallel edges (simplices) we need to be careful to specify boundary. In case of simplicial complex we take fist thing with given vertrices as part of boundary. If there are multiple simplices with the same boundary this may give unintended results. So in simplicial complex we should check for duplicates and either remove them or signal error. Delta complex is different: here duplication is explicitely handled. > > - apparently you want chains here. Chains are not the same as > > complexes. > > I take your point and I would like to pursue your earlier comments about > having a separate chain domain (though I'm not sure exactly how). Chains are free module generated by facets (with canonical orientation). So you may be able to reuse functions from FreeModule. -- 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 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 19/09/16 20:25, Kurt Pagani wrote: However, you can get the current handbook from github if you are interested: https://github.com/gheber/kenzo/raw/master/doc/Kenzo-Doc.pdf https://github.com/gheber/kenzo I have only just skimmed through so far but Kenzo does look very interesting. It looks like they have found a way to code structures like fibrations, spectral sequences and relating chain complexes to structures like algebras, coalgebras, and much more. I think it would be good to include structures like these in FriCAS. I guess we need to get the basics right first but I also like to try to work out a long term path for where this is headed. Thank you for coding the dunceHat example. I will write a patch to include this in SimplicialComplexFactory. 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 20/09/16 16:06, Waldek Hebisch wrote: > You are confused. It happens! I have tried the patch and AFAICS it works fine, I would be happy if it were applied. > As a face (part of simplical complex) (1,3) and > (3, 1) are the same face. And problem is not due to wrong > orientation of input: I remember now, it is the same face but we allow it to be included multiple times in different orientations: (1) -> ASIMP := FiniteSimplicialComplex(VertexSetAbstract) (1) FiniteSimplicialComplex(VertexSetAbstract) Type: Type (2) -> v2a:List(List(NNI)) := [[1,3],[1,3],[3,1]] (2) [[1,3],[1,3],[3,1]] Type: List(List(NonNegativeInteger)) (3) -> sc1 := simplicialComplex(vertexSeta(3::NNI),v2a)$ASIMP (3) (1,3) (1,3) -(1,3) Type: FiniteSimplicialComplex(VertexSetAbstract) (4) -> addImpliedFaces(sc1) (4) [[-(1,3),(1,3),(1,3)]] Type: List(List(OrientedFacet)) (5) -> sc1::DeltaComplex(VertexSetAbstract) (5) 1D:[[1,- 2],[1,- 2],[- 1,2]] Type: DeltaComplex(VertexSetAbstract) Under a strict geometric interpretation of a definition of simplicialComplex I suspect that this should not be allowed? But, as we discussed earlier, it is useful not to prevent this to allow construction of interesting delta complexes. > - apparently you want chains here. Chains are not the same as > complexes. I take your point and I would like to pursue your earlier comments about having a separate chain domain (though I'm not sure exactly how). 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.
Re: [fricas-devel] Algebraic Topology Issue 1
AFAICS the attached patch fixes the problem:
--
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 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.
--- ../ax-build195/src/algebra/SIMPC.spad 2016-09-19 22:51:14.843152617
+
+++ SIMPC.spad 2016-09-20 15:40:21.479430962 +
@@ -247,7 +247,7 @@
reslt := concat(reslt, orderedPermutation(rst, len))
reslt
- -- local function used in listUnion in addImpliedFaces
+ -- local function used in unorientedUnion in addImpliedFaces
isNewFace?(lst : List(OrientedFacet), b : OrientedFacet) : Boolean ==
--print("isNewFace?(" << a << ", " << b << ")")
for a in lst repeat
@@ -256,17 +256,17 @@
true
-- local function used in addImpliedFaces
- listUnion(a : List(OrientedFacet), b : List(OrientedFacet)
+ unorientedUnion(a : List(OrientedFacet), b : List(OrientedFacet)
) : List(OrientedFacet) ==
- res := []$List(OrientedFacet)
- for a1 in a repeat
- res := concat(res, a1)
+ res := a
for b1 in b repeat
if isNewFace?(a, b1) then
- res := concat(res, b1)
- --print("listUnion(" << a << ", " << b << ") = " << res)
+ res := cons(b1, res)
+ -- print("unorientedUnion(" << a << ", " << b << ") = " << res)
res
+ import from OutputForm
+
-- A function to take a set of faces and add those that are implied
-- by the simplicial complex conventions (if they don't already exist).
-- For example, if the input is a triangle ((1, 2, 3)) then we would add
@@ -280,27 +280,29 @@
--print("addImpliedFaces return because maxGrade=" << maxGrade)
return res
-- create an empty list for each grade
- for a in 1..(maxGrade) repeat
- res := concat(res, []$List(OrientedFacet))
+ res := []$List(List(OrientedFacet))
newFaces := []$List(OrientedFacet)
- for gr in inputList for grn in 1..(maxGrade) repeat
+ for gr in inputList repeat
--print("addImpliedFaces grade number grn=" << grn)
-- add old faces
- for face in gr repeat
- res.grn := concat(res.grn, face)
- -- add new faces
- for face in newFaces repeat
- res.grn := concat(res.grn, face)
+ all_faces := unorientedUnion(newFaces, gr)
+ -- print(message("all_faces = "))
+ -- print(all_faces::OutputForm)
+ res := cons(all_faces, res)
--print("addImpliedFaces empty newFaces. res.grn=" << res.grn)
- newFaces := []$List(OrientedFacet)
+ newFaces := []
--print("addImpliedFaces res.grn=" << res.grn)
- for face in res.grn repeat
+ for face in all_faces repeat
+ -- FIXME: handle order 1 too
len : NNI := (order(face) -1) pretend NNI
if len > 0 then
- newFaces := listUnion(newFaces, allSubsets(face, len, len))
+ newFaces := unorientedUnion(newFaces,
+ allSubsets(face, len, len))
+ -- print(message("newFaces = "))
+ -- print(newFaces::OutputForm)
--print("addImpliedFaces get next grade res=" << res)
--print("addImpliedFaces result=" << reverse(res))
- reverse(res)
+ res
-- Step down to the next lower dimension, this is like hollowing out the
complex.
-- It takes the highest dimension entries and replaces them with their
boundaries,
Re: [fricas-devel] Algebraic Topology Issue 1
Martin Baker wrote: > > On 19/09/16 11:17, Waldek Hebisch wrote: > > AFAICS code which allows omiting lower > > dimensional faces is buggy, if we include lower dimensional > > faces we get duplicate simplices. In particular, all > > faces of triangle are duplicated and we get three extra > > loops. > > Are sure this is buggy? > AFAICS we need to take orientation into account and orientation requires > a consistent set of notation standards. Could it be that other programs > are using different conventions? > > (1) -> triangle := sphereSolid(2)$SimplicialComplexFactory > > (1) > (1,2,3) > Type: FiniteSimplicialComplex(VertexSetAbstract) > (2) -> delta(triangle) > > (2) > (1,2) > -(1,3) > (2,3) > Type: FiniteSimplicialComplex(VertexSetAbstract) > > So [(1,2),-(1,3), (2,3)] represents a circular chain (boundary of a > triangle). > > Which can be notated [(1,2),(3,1), (2,3)] > > OTOH [(1,2), (1,3), (2,3)] represents two parallel chains, starting and > ending at the same vertices. This will have different homology. You are confused. As a face (part of simplical complex) (1,3) and (3, 1) are the same face. And problem is not due to wrong orientation of input: v2b:List(List(NNI)) := [[1,2],[3,1],[2,3],[1,2,3]] si2 := simplicialComplex(vertexSeta(3::NNI),v2b)$ASIMP (20) -> homology(si2) (20) [Z,Z*3,0] Type: List(Homology) (21) -> addImpliedFaces(si2) (21) [[(1,2),-(1,3),(2,3),(2,3),(1,3),(1,2)],[(1,2,3)]] Type: List(List(OrientedFacet)) Here orientation of one-dimensional edges agrees with boundary of two-dimensional simplex, but we get duplicated edges. AFAICS the problem is that 'addImpliedFaces' detects duplicates between boundary faces, but ignores possible duplication between explicitely provided faces and boundary faces. Oriententin in 'addImpliedFaces' just add some unnecessary complication because duplication should be detected diregarding orientation so it would be simpler to use unoriented faces here. Working with oriented faces means the we need something like your signed 'position' from OrientedFacet. > These conventions make sense to me because all we need to do is order > the facets (left entry is most significant) and then alternate the sign. > > This is what concerns me about your proposal, for changing the VertexSet > structure, the user interface could then loose this ordering information. > > So is this Cyclic? > [(a,b),-(a,c), (b,c)] > > I would say yes, but only if ac, but the user can't know > this because they can't see the underlying index ordering. Hmm: - apparently you want chains here. Chains are not the same as complexes. - in homology cyclic means that boudary is zero. You get zero boundary from the chain _regardless_ of underlying index ordering. Different ordering can change orientation of edges and hence boundaries of edges, but the boundary of chain will change in consistent way, in partucular zero boundary will remain zero boudary. - you may be thinking homotopy here. You can get the same one-dimensional chain (in fact cycle) from two inequivalent loops. -- 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 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.
Re: [fricas-devel] Algebraic Topology Issue 1
Martin, after a look into your code I think there was a deep misunderstanding - my fault :( Kenzo indeed works slightly different, so I tacitly assumed one needs the full base of the triangulation w.r.t the bdry homomorphism. Your method instead requires properly oriented input. Now I also conceive that you find the idea of vertex sets rather odd. So, actually, your UI is expecting a formal sum (a Z2-Module over a set of cells if you like): dunceHat = [1,2,8]+[2,3,8]+[3,7,8]+[3,1,7]+[1,2,7]+[1,8,6]+[1,6,2]+[8,7,6]+[2,6,4]+[6,7,5]+[7,2,5]+[6,5,4]+[2,4,3]+[2,3,5]+[4,1,3]+[4,5,1]+[5,3,1] = [1,2,8]+[2,3,8]+[3,7,8]-[1,3,7]+[1,2,7]-[1,6,8]-[1,2,6]-[6,7,8]-[2,4,6]+[5,6,7]+[2,5,7]-[4,5,6]-[2,3,4]+[2,3,5]+[1,3,4]+[1,4,5]-[1,3,5] => now we get the correct result (cmp fig. on p.67): ASIMP := FiniteSimplicialComplex(VertexSetAbstract) (1) -> v1:List(List(NNI)) :=[[1,2,8],[2,3,8],[3,7,8],[3,1,7],[1,2,7], _ [1,8,6],[1,6,2],[8,7,6],[2,6,4],[6,7,5],[7,2,5],[6,5,4], _ [2,4,3],[2,3,5],[4,1,3],[4,5,1],[5,3,1]] (1) [[1,2,8], [2,3,8], [3,7,8], [3,1,7], [1,2,7], [1,8,6], [1,6,2], [8,7,6], [2,6,4], [6,7,5], [7,2,5], [6,5,4], [2,4,3], [2,3,5], [4,1,3], [4,5,1], [5,3,1]] Type: List(List(NonNegativeInteger)) (2) -> dunceHat := simplicialComplex(vertexSeta(8::NNI),v1)$ASIMP (2) (1,2,8) (2,3,8) (3,7,8) -(1,3,7) (1,2,7) -(1,6,8) -(1,2,6) -(6,7,8) -(2,4,6) (5,6,7) (2,5,7) -(4,5,6) -(2,3,4) (2,3,5) (1,3,4) (1,4,5) -(1,3,5) Type: FiniteSimplicialComplex(VertexSetAbstract) (3) -> homology dunceHat (3) [Z,0,0] Type: List(Homology) Sorry for any inconvenience caused. Kurt > AFAICS we need to take orientation into account and orientation requires > a consistent set of notation standards. Could it be that other programs > are using different conventions? > > (1) -> triangle := sphereSolid(2)$SimplicialComplexFactory > >(1) > (1,2,3) > Type: FiniteSimplicialComplex(VertexSetAbstract) > (2) -> delta(triangle) > > (2) > (1,2) >-(1,3) > (2,3) > Type: FiniteSimplicialComplex(VertexSetAbstract) > > So [(1,2),-(1,3), (2,3)] represents a circular chain (boundary of a > triangle). > > Which can be notated [(1,2),(3,1), (2,3)] > > OTOH [(1,2), (1,3), (2,3)] represents two parallel chains, starting and > ending at the same vertices. This will have different homology. > > These conventions make sense to me because all we need to do is order > the facets (left entry is most significant) and then alternate the sign. > > This is what concerns me about your proposal, for changing the VertexSet > structure, the user interface could then loose this ordering information. > > So is this Cyclic? > [(a,b),-(a,c), (b,c)] > > I would say yes, but only if ac, but the user can't know > this because they can't see the underlying index ordering. > > 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.
Re: [fricas-devel] Algebraic Topology Issue 1
> Well since these values are potentially being used as indexes into > VertexSet and since the usual FriCAS default is 1-based indexing I used > that. > I see. I guess you're already thinking of geometric realizations (list of vectors?). But what if you remove a vertex or whole parts of the complex? Can your implementation handle such cases (auto relabelling)? > > However Waldek has suggested replacing VertexSet with any SetCategory > which would allow indexes to be hidden from user interface. This would > allow any values to be used here. > Would certainly be more flexible :) On the other hand NNI will surely be sufficient for practical purposes as long as it's not required to be "consecutive" (meaning I can use any subset of NNI). > > I will therefore attempt to implement Waldeks suggestion. > > -- 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 19/09/16 11:17, Waldek Hebisch wrote: AFAICS code which allows omiting lower dimensional faces is buggy, if we include lower dimensional faces we get duplicate simplices. In particular, all faces of triangle are duplicated and we get three extra loops. Are sure this is buggy? AFAICS we need to take orientation into account and orientation requires a consistent set of notation standards. Could it be that other programs are using different conventions? (1) -> triangle := sphereSolid(2)$SimplicialComplexFactory (1) (1,2,3) Type: FiniteSimplicialComplex(VertexSetAbstract) (2) -> delta(triangle) (2) (1,2) -(1,3) (2,3) Type: FiniteSimplicialComplex(VertexSetAbstract) So [(1,2),-(1,3), (2,3)] represents a circular chain (boundary of a triangle). Which can be notated [(1,2),(3,1), (2,3)] OTOH [(1,2), (1,3), (2,3)] represents two parallel chains, starting and ending at the same vertices. This will have different homology. These conventions make sense to me because all we need to do is order the facets (left entry is most significant) and then alternate the sign. This is what concerns me about your proposal, for changing the VertexSet structure, the user interface could then loose this ordering information. So is this Cyclic? [(a,b),-(a,c), (b,c)] I would say yes, but only if ac, but the user can't know this because they can't see the underlying index ordering. 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 19/09/16 12:00, Ralf Hemmecke wrote: I can only speak for firefox, but you should note that forging a http connection is easier than forging a https connection. If you allow Firefox to do an exception for the above site (note that you don't need to accept that exception "permanently" -- deselect the checkbox), it means that you connect to the site in an encrytped way. So the connection to the target site is encrypted, the only thing that you don't know is that the site is the site it claims to be and that nobody has led you to a wrong site. With http, you neither have encryption nor can you be sure that someone led you to the wrong site. As I see it, this sites certificate simply has expired. So it would probably be a good thing to tell thit to the webmaster of www-fourier.ujf-grenoble.fr. As long as you trust that the .pdf does not have a virus, I think, it's not a problem if one trusts "self-signed certificates". Although nowadays people should probably switch to "Let's encrypt"-certificates. https://letsencrypt.org/ Ralf OK, thanks, I'll do that. -- 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 09/19/2016 11:54 AM, Martin Baker wrote: > >> BTW: why didn't you allow '0'? NNI=0,1,2,... ;) >> >> >> -- from https://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/Kenzo-doc.pdf > > Neither Firefox nor Chrome would allow me to connect to this site, I got: > > "Your connection is not secure > The owner of www-fourier.ujf-grenoble.fr has configured their website > improperly. To protect your information from being stolen, Firefox has > not connected to this website." > > Even when I changed https to http it automatically changed it back and > would not connect. Yes and that is a feature. I can only speak for firefox, but you should note that forging a http connection is easier than forging a https connection. If you allow Firefox to do an exception for the above site (note that you don't need to accept that exception "permanently" -- deselect the checkbox), it means that you connect to the site in an encrytped way. So the connection to the target site is encrypted, the only thing that you don't know is that the site is the site it claims to be and that nobody has led you to a wrong site. With http, you neither have encryption nor can you be sure that someone led you to the wrong site. As I see it, this sites certificate simply has expired. So it would probably be a good thing to tell thit to the webmaster of www-fourier.ujf-grenoble.fr. As long as you trust that the .pdf does not have a virus, I think, it's not a problem if one trusts "self-signed certificates". Although nowadays people should probably switch to "Let's encrypt"-certificates. https://letsencrypt.org/ Ralf -- 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.
Re: [fricas-devel] Algebraic Topology Issue 1
Kurt Pagani wrote: > -- Diabolo > > v2:List(List(NNI)) := [[1],[2],[3],[4],[5],[6], _ > [1,2],[1,3],[2,3],[3,4],[4,5],[4,6],[5,6], _ > [4,5,6]] > > > diabolo:= simplicialComplex(vertexSeta(6::NNI),v2)$ASIMP > > homology diabolo > > -- [Z,Z*4,0] , actually H0=Z, H1=Z, H2=0. If you do: v2a := [[1,2],[1,3],[2,3],[3,4],[4,5,6]] diabolo := simplicialComplex(vertexSeta(6::NNI),v2a)$ASIMP then it works. AFAICS code which allows omiting lower dimensional faces is buggy, if we include lower dimensional faces we get duplicate simplices. In particular, all faces of triangle are duplicated and we get three extra loops. This is visible in the generated chain: (15) -> chain(diabolo) (15) + 0 + | | | 0 | | | + 1100000000 + | 0 | || | | |- 1 010000000 | | 0 | || | | | 0 - 1 - 1 1000000 | | 1 | [0 0 0 0 0 0],||,| | | 000 - 1 111100 | | 0 | || | | | 0000 - 1 - 1 0011 | |- 1| || | | + 000000 - 1 - 1 - 1 - 1+ | 0 | | | | 1 | | | + 0 + , edeges 5 and 6 form duplicate pair, with 5 beeing boundary of triangle. The same for pairs 7 and 8 and for pair 9 and 10. -- 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 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 19/09/16 04:59, Kurt Pagani wrote: Hello Martin As promised (before vacation) below two examples which I'm unable to interpret (otherwise I recognized that you've improved your code and that it's now included in fricas -- great :). A lot more examples work now (i.e same results as Kenzo). Thanks, very much, for checking this. BTW: why didn't you allow '0'? NNI=0,1,2,... ;) -- from https://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/Kenzo-doc.pdf Neither Firefox nor Chrome would allow me to connect to this site, I got: "Your connection is not secure The owner of www-fourier.ujf-grenoble.fr has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website." Even when I changed https to http it automatically changed it back and would not connect. ASIMP := FiniteSimplicialComplex(VertexSetAbstract) v0:List(List(NNI)) :=[[0],[1],[2],[3],[4],[5],[6],[7], _ [0,1],[0,2],[0,3], _ [0,4],[0,5],[0,6], _ [0,7],[1,2],[1,3], _ [1,4],[1,5],[1,6], _ [1,7],[2,3],[2,4], _ [2,6],[2,7],[3,4], _ [3,5],[4,5],[4,6], _ [5,6],[5,7],[6,7], _ [0,1,5],[0,1,6],[0,1,7], _ [0,2,3],[0,2,4],[0,2,6], _ [0,3,4],[0,5,7],[1,2,3], _ [1,2,4],[1,2,7],[1,3,5], _ [1,4,6],[2,6,7],[3,4,5], _ [4,5,6],[5,6,7]] Well since these values are potentially being used as indexes into VertexSet and since the usual FriCAS default is 1-based indexing I used that. However Waldek has suggested replacing VertexSet with any SetCategory which would allow indexes to be hidden from user interface. This would allow any values to be used here. I will therefore attempt to implement Waldeks suggestion. On 05/09/16 01:17, Waldek Hebisch wrote: > No. My suggestion is to have: > > FiniteSimplicialComplex(VS : SetCategory) > ... > Rep := Record(VERTSET : List(VS), SIMP : List(OrientedFacet)) > > SIMP can use numbers from 1 to n. VERTSET gives correspondence > between numbers and vertices. On 19/09/16 04:59, Kurt Pagani wrote: -- Dunce hat -- https://en.wikipedia.org/wiki/Dunce_hat_(topology) v1:List(List(NNI)) :=[[1],[2],[3],[4],[5],[6],[7],[8], _ [1,2],[1,3],[1,4], _ [1,5],[1,6],[1,7], _ [1,8],[2,3],[2,4], _ [2,5],[2,6],[2,7], _ [2,8],[3,4],[3,5], _ [3,7],[3,8],[4,5], _ [4,6],[5,6],[5,7], _ [6,7],[6,8],[7,8], _ [1,2,6],[1,2,7],[1,2,8], _ [1,3,4],[1,3,5],[1,3,7], _ [1,4,5],[1,6,8],[2,3,4], _ [2,3,5],[2,3,8],[2,4,6], _ [2,5,7],[3,7,8],[4,5,6], _ [5,6,7],[6,7,8]] I don't think all these values are necessary because any set is assumed to contain all its subsets. However, explicitly including them should not cause a problem. I will try to investigate what is going on. Thanks again, 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.
Re: [fricas-devel] Algebraic Topology Issue 1
Hello Martin As promised (before vacation) below two examples which I'm unable to interpret (otherwise I recognized that you've improved your code and that it's now included in fricas -- great :). A lot more examples work now (i.e same results as Kenzo). BTW: why didn't you allow '0'? NNI=0,1,2,... ;) -- from https://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/Kenzo-doc.pdf --- ASIMP := FiniteSimplicialComplex(VertexSetAbstract) v0:List(List(NNI)) :=[[0],[1],[2],[3],[4],[5],[6],[7], _ [0,1],[0,2],[0,3], _ [0,4],[0,5],[0,6], _ [0,7],[1,2],[1,3], _ [1,4],[1,5],[1,6], _ [1,7],[2,3],[2,4], _ [2,6],[2,7],[3,4], _ [3,5],[4,5],[4,6], _ [5,6],[5,7],[6,7], _ [0,1,5],[0,1,6],[0,1,7], _ [0,2,3],[0,2,4],[0,2,6], _ [0,3,4],[0,5,7],[1,2,3], _ [1,2,4],[1,2,7],[1,3,5], _ [1,4,6],[2,6,7],[3,4,5], _ [4,5,6],[5,6,7]] -- Dunce hat -- https://en.wikipedia.org/wiki/Dunce_hat_(topology) v1:List(List(NNI)) :=[[1],[2],[3],[4],[5],[6],[7],[8], _ [1,2],[1,3],[1,4], _ [1,5],[1,6],[1,7], _ [1,8],[2,3],[2,4], _ [2,5],[2,6],[2,7], _ [2,8],[3,4],[3,5], _ [3,7],[3,8],[4,5], _ [4,6],[5,6],[5,7], _ [6,7],[6,8],[7,8], _ [1,2,6],[1,2,7],[1,2,8], _ [1,3,4],[1,3,5],[1,3,7], _ [1,4,5],[1,6,8],[2,3,4], _ [2,3,5],[2,3,8],[2,4,6], _ [2,5,7],[3,7,8],[4,5,6], _ [5,6,7],[6,7,8]] dunceHat := simplicialComplex(vertexSeta(8::NNI),v1)$ASIMP homology dunceHat -- [Z,Z*24,0] , actually H0=Z, others 0. -- Diabolo v2:List(List(NNI)) := [[1],[2],[3],[4],[5],[6], _ [1,2],[1,3],[2,3],[3,4],[4,5],[4,6],[5,6], _ [4,5,6]] diabolo:= simplicialComplex(vertexSeta(6::NNI),v2)$ASIMP homology diabolo -- [Z,Z*4,0] , actually H0=Z, H1=Z, H2=0. Am 06.09.2016 um 11:24 schrieb Martin Baker: > Martin B > Kurt -- 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.
Re: [fricas-devel] Algebraic Topology Issue 1
On 05/09/16 01:17, Waldek Hebisch wrote: No. My suggestion is to have: FiniteSimplicialComplex(VS : SetCategory) ... Rep := Record(VERTSET : List(VS), SIMP : List(OrientedFacet)) SIMP can use numbers from 1 to n. VERTSET gives correspondence between numbers and vertices. I can see the merit in this. When users are just using abstract (combinatorial) topology they can use: FiniteSimplicialComplex(NNI) or FiniteSimplicialComplex(Symbol) But if some 'geometry' is involved then VS will have to be something more complicated and some part of the software will have to 'see' inside this SetCategory. This geometry is not just for graphical interface (important to me as this is) but it is also genuine mathematical content, for example I would like to distinguish isotopy, that is embeddings in higher dimensions, where a trefoil knot is different from a circle for example also we need guarantee that facets do not intersect. Perhaps FiniteSimplicialComplex could implement mostly just the abstract stuff and the geometry could be done externally in other domains or packages? As you point out, constructors and output will have to be more complicated to do this. In order to keep the output to a manageable size I think I will need something like the following in coerce to OutputForm: if (VS is NNI) or (VS is PI) or (VS is Integer) or (VS is Symbol) then map_to_VS_in_output() else use_index_in_output() That is, if VS is something compact (like a number or a symbol) then use that in the output but if it is something more complicated (like a coordinate) then just display the index instead. Would this work? Is there a less messy way to see inside VS? Part of your confusion may come from fact that in textbooks chains play important role, but you have not direct representation of chains. You represent chains as list of cells, which means that 0 chain is represented as empty list. But you do not have operations on chains like addition or multiplication by scalar. In a sense adding chains is trivial, all you need is FreeModule(Integer, Facet), but you do not have Facet, you only have OrientedFacet. Instead of Facet one could use say Set(Integer), but then this becomes completely disconnected from your code. This looks like an interesting idea. I guess this would only work for DeltaComplex and not FiniteSimplicialComplex because the facets need to be graded. Do you think it would be a problem having both (since it involves some duplication). So we have: Facet for DeltaComplex OrientedFacet for FiniteSimplicialComplex It seems to me that one of the big advantages of panaxiom is its type system and so that should be used to enforce the grading. That is, if we try to add Facets of different dimensions that will be detected at compile time rather than runtime. So can we define a facet type like this: Facet(n:NNI) -- an 'n' dimensional facet. We can then define a chain like this: Chain(n:NNI) ... Rep := FreeModule(Integer, Facet(n)) Could we define a boundary map like this: BoundaryMap(n:NNI) ... Rep := Chain(n) -> Chain(n-1) Not sure how practical this is? In practice, for finite dimensions, we would just hide a lookup table inside a lambda so perhaps we might as well put the lookup table directly in the Rep: Rep := List(List(Integer))) We then need a way to define DeltaComplex, a bit like this: DeltaComplex(n:NNI,VS : VertexSet) ... Rep := Record(VERTSET : VS, MAPS : [BoundaryMap(m) for m in n..1]) but that does not work. Is there a way to have comprehensions for types? Or is there some other way to do this? 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.
Re: [fricas-devel] Algebraic Topology Issue 1
Martin Baker wrote" > > I guess I could send you some patches and see if you accept them, but it > seems more efficient to discuss the options first and then I could write > a patch for the option which you and others on this list think is best. > > So, assuming that is acceptable, here is the first issue: > > Description of Issue > > On 30/08/16 16:43, Waldek Hebisch wrote: > > 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. > > There are some wider issues about VertexSet such as how to work with > cochains and so on but I was hoping to discuss that as a separate issue. > > Can we disallow renumbering vertices in a way that would leave gaps? I > think it might be best to require that there are no gaps in the vertex > numbers, that is the vertex numbers go through 1..n without missing out > any. This is all that is needed for combinatorics but for geometry I > tend to think of this as an index into the geometry information. At the level of representation such restriction is OK. As part of user interface it is too restrictive. > The Rep for FiniteSimplicialComplex is: > Rep := Record(VERTSET : VS, SIMP : List(OrientedFacet)) > > and the Rep for OrientedFacet is: > Rep := Record(mul : Integer, fac : List(NNI)) > > Are you suggesting that this is changed to this: > > The Rep for FiniteSimplicialComplex would be: > Rep := List(OrientedFacet) > > and the Rep for OrientedFacet would be: > Rep := Record(mul : Integer, fac : List(VS)) No. My suggestion is to have: FiniteSimplicialComplex(VS : SetCategory) ... Rep := Record(VERTSET : List(VS), SIMP : List(OrientedFacet)) SIMP can use numbers from 1 to n. VERTSET gives correspondence between numbers and vertices. > I think that indexing, as currently implemented, is the only practical > option. A simplicial complex might be very large, we want it to scale > up. If we are using geometric coordinates then, a simplicial complex > contains multiple references to each vertex, so typing it from the CLI > would require the user to type each coordinates multiple times also the > CLI output would probably be complex and long with multiple copies of > each coordinate. I also suspect that indexes are much more efficient to > compare and work with than coordinates which may contain floating point > values which may have rounding errors. There is difference between user interface and internal representation. If user is happy with vertices beeing 1..n, then we can provide appropriate constructor. But for example, we should also provide a 'map' between simplical complexes on different set, so that user can specify mapping on vertices and it would be automatically extended to simplicial complexes. Basically, for most categories we have SomeCatFunctons2(dom1, dom2) which provides 'map' between domains. With representation as I propesed above if mapping is 1 to 1 then we need to only change list of vertices. In other cases we need to colapse vertices which requires some effort. Concerning user interface: in textbooks main method to build new spaces is to perform some operation on simpler spaces. For example, sum of two spaces with single common point. Or sum with some common subspace. 'map' may be used to produce quotient space. So supporting vertex sets different from 1..n is essential for specifying some examples. And the point is that we need this support at user interface level, what happens with representation is internal matter of the domain. > I think the above also applies to DeltaComplex although it would be > possible to remove geometry information from DeltaComplex especially > where it is used to hold topologies with the same point or edge > appearing in different places. > > So if we start with FiniteSimplicialComplex containing VertexSet and we > want to calculate homology, converting to DeltaComplex would be the > first stage of this and loosing geometric information would not matter > because its not needed for homology. However I am not sure that this is > true for cohomology so I would like to retain VertexSet
[fricas-devel] Algebraic Topology Issue 1
Waldek, Thank you for including the algebraic topology in 1.3.0 despite some remaining issues. I thought the best way to tackle those issues is to look at them, one at a time, then try to work out a separate patch for each one. I guess I could send you some patches and see if you accept them, but it seems more efficient to discuss the options first and then I could write a patch for the option which you and others on this list think is best. So, assuming that is acceptable, here is the first issue: Description of Issue On 30/08/16 16:43, Waldek Hebisch wrote: > 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. There are some wider issues about VertexSet such as how to work with cochains and so on but I was hoping to discuss that as a separate issue. Can we disallow renumbering vertices in a way that would leave gaps? I think it might be best to require that there are no gaps in the vertex numbers, that is the vertex numbers go through 1..n without missing out any. This is all that is needed for combinatorics but for geometry I tend to think of this as an index into the geometry information. The Rep for FiniteSimplicialComplex is: Rep := Record(VERTSET : VS, SIMP : List(OrientedFacet)) and the Rep for OrientedFacet is: Rep := Record(mul : Integer, fac : List(NNI)) Are you suggesting that this is changed to this: The Rep for FiniteSimplicialComplex would be: Rep := List(OrientedFacet) and the Rep for OrientedFacet would be: Rep := Record(mul : Integer, fac : List(VS)) I think that indexing, as currently implemented, is the only practical option. A simplicial complex might be very large, we want it to scale up. If we are using geometric coordinates then, a simplicial complex contains multiple references to each vertex, so typing it from the CLI would require the user to type each coordinates multiple times also the CLI output would probably be complex and long with multiple copies of each coordinate. I also suspect that indexes are much more efficient to compare and work with than coordinates which may contain floating point values which may have rounding errors. I think the above also applies to DeltaComplex although it would be possible to remove geometry information from DeltaComplex especially where it is used to hold topologies with the same point or edge appearing in different places. So if we start with FiniteSimplicialComplex containing VertexSet and we want to calculate homology, converting to DeltaComplex would be the first stage of this and loosing geometric information would not matter because its not needed for homology. However I am not sure that this is true for cohomology so I would like to retain VertexSet in DeltaComplex until we know the requirements for cohomology. I would like to decouple the link to VertexSet slightly as explained below. Test Case - This illustrates a bug when converting FiniteSimplicialComplex to DeltaComplex. We create a simplicial complex containing an edge and 1 unconnected point, this is then converted to a delta complex which contains only the line but the additional point is missing: (1) -> ASIMP := FiniteSimplicialComplex(VertexSetAbstract) (1) FiniteSimplicialComplex(VertexSetAbstract) Type: Type (2) -> v1:List(List(NNI)) := [[1::NNI,2::NNI],[3::NNI]] (2) [[1,2],[3]] Type: List(List(NonNegativeInteger)) (3) -> sc1 := simplicialComplex(vertexSeta(3::NNI),v1)$ASIMP (3) (1,2) (3) Type: FiniteSimplicialComplex(VertexSetAbstract) (4) -> )expose DeltaComplex DeltaComplex is now explicitly exposed in frame frame1 (4) -> d1 := deltaComplex(sc1) (4) 1D:[[1,- 2]] Type: DeltaComplex(VertexSetAbstract) Options --- How to fix this bug? deltaComplex should be reading in the number of verticies from the vertexSet and making sure any unconnected vertices are included, it is not doing that so I could just implement it as intended. However, I think it would be better to include the information in the face map and
