Opened 11 years ago

Closed 10 years ago

#11384 closed enhancement (fixed)

Construct the complex of a fan

Reported by: vbraun Owned by: AlexGhitza
Priority: major Milestone: sage-5.0
Component: algebraic geometry Keywords: sd31
Cc: novoselt Merged in: sage-5.0.beta5
Authors: Volker Braun Reviewers: Andrey Novoseltsev
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #11558 Stopgaps:

Status badges

Description (last modified by 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

Attachments (2)

trac_11384_fan_complex.2.patch (11.9 KB) - added by vbraun 11 years ago.
Updated patch
trac_11384_fan_complex.patch (11.8 KB) - added by vbraun 10 years ago.
Updated patch

Download all attachments as: .zip

Change History (18)

comment:1 Changed 11 years ago by vbraun

  • Cc novoselt added
  • Status changed from new to needs_review

comment:2 Changed 11 years ago by vbraun

  • Authors set to Volker Braun

comment:3 Changed 11 years ago by novoselt

  • Keywords sd31 added
  • Reviewers set to Andrey Novoseltsev
  • Status changed from needs_review to needs_work
  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).

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by vbraun

  • Status changed from needs_work to needs_review

comment:6 Changed 11 years ago by vbraun

  • Dependencies set to #11558, #11559

Updated doctests because #11559 changes the ordering.

Changed 11 years ago by vbraun

Updated patch

comment:7 Changed 11 years ago by vbraun

  • Description modified (diff)

comment:8 Changed 10 years ago by vbraun

Apply trac_11384_fan_complex.patch

comment:9 Changed 10 years ago by novoselt

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

Changed 10 years ago by vbraun

Updated patch

comment:10 Changed 10 years ago by vbraun


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

comment:11 Changed 10 years ago by novoselt

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

comment:12 Changed 10 years ago by vbraun

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


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

comment:13 Changed 10 years ago by novoselt

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

comment:14 Changed 10 years ago by vbraun

  • Dependencies changed from #11558, #11559 to #11558

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

comment:15 Changed 10 years ago by novoselt

  • Status changed from needs_review to positive_review

That ticket has a really challenging number ;-)

comment:16 Changed 10 years ago by jdemeyer

  • Merged in set to sage-5.0.beta5
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.