Construct the complex of a fan

[vbraun]

For some toric algorithms one needs to choose orientations for cones, essentially to construct the homology complex of the cone complex. This patch implements new methods fan.oriented_boundary(cone) and fan.complex() to return chosen boundary orientations of cones and the resulting homology complex.

Apply trac_11384_fan_complex.patch​

[novoselt]

1. In oriented_boundary can we replace throughout cone with something more neutral, like cell or part, since it is allowed to be the whole fan?
2. What exactly is "outward normal first" orientation?
3. How about representing the output of oriented_boundary as a formal sum with plus/minus 1 coefficients? Wouldn't it be more convenient?
4. It would be nice to be more clear what is arbitrary and what is not. As I understand, the only randomness is in the choice of orientation of non-full-dimensional *generating* cones, the rest is then determined.
5. To reduce randomness of the last case, perhaps one can compute the determinant of the pivot matrix of the (cone rays | identity) matrix)? It may perhaps be also a little faster than working with quotients.
6. The code crashes on

   sage: fan = toric_varieties.P(3).fan() 
   sage: cone = fan(0)[0] 
   sage: fan.oriented_boundary(cone) 
   

7. Are there any references that would be suitable to put into documentation of complex method? What is it used for and what is computed by its homology groups? Is it possible to have torsion? I guess yes, since QQ would be faster otherwise, but it would be nice to have an example!
8. Would be nice also to say something about the differential maps and why it is possible to define the extended complex for complete fans.
9. "The orientation of each cone is chose as..." must be "chosen".
10. Is there a reason why "-1" term is printed in the end? It looks like a bug (not in this patch, of course).

[vbraun]

1. The normal usage is oriented_boundary(cone), so I would prefer keeping the argument name as it is. Yes it also accepts a fan as a special case, but trying to be general for generality's sake would make the help less helpful, not more.
2. "ONF": One Never Forgets - Outward Normal First. Mnemonic for the usual boundary orientation choice in algebraic geometry.
3. Sounds like a good idea. I'll look into it
4. No, all orientations are arbitrary. Only the relative orientations of (cone,face) is not. The whole point of the method is a way to fix one particular orientation such that one can write down the boundary complex explicitly.
5. I'm sure there are optimizations but speed hasn't been a bottleneck for me so far. Better to be correct than fast.
6. Ok will fix that.
7. It has the homology type of a point, so you can't compute anything interesting by itself. It provides a way to fix one (arbitrary choice of) orientations for all cones, mostly. I'll add a reference.
8. I don't really have something clever to say about the extended complex. Its rather obvious that it works.
9. Ok will fix it.
10. in the homology() of a simplicial complex? It probably depends on the algorithm that SimplicialComplex uses to compute the homology.

[vbraun]

Updated doctests because #11559 changes the ordering.

[vbraun]

Updated patch

[vbraun]

Apply trac_11384_fan_complex.patch

[novoselt]

Line 2656 still has "chose" instead of "chosen" ;-)

[vbraun]

Updated patch

[vbraun]

Fixed!

Also fixed some doctests that relied on the order of boundary cones, I think something changed in the poses stuff. Now applies cleanly against sage-5.0.beta4

[novoselt]

Is #11599 still supposed to be in front? That one has to be rebased as well.

[vbraun]

I didn't have to rebase #11599, my patch queue is:

trac_12280_padic_hnf_without_zero_rows.patch
trac_11384_fan_complex.patch
trac_11599_no_circular_imports.patch
trac_11599_homset_new_coercion_model.patch
trac_11599_rename_morphisms.patch
trac_11599_toric_morphisms.patch
trac_11599_reviewer.patch

I'm working on implementing your requests there, though.

[novoselt]

Oops, sorry - I meant #11559, which is the second dependency here.

[vbraun]

Oh yes I removed the dependency on #15599, forgot to remove it from the ticket description.

[novoselt]

That ticket has a really challenging number ;-)