Opened 11 years ago

Closed 11 years ago

#10882 closed enhancement (fixed)

Add kernel fan to fan morphism

Reported by: novoselt Owned by: mhampton
Priority: major Milestone: sage-4.7.1
Component: geometry Keywords: toric geometry
Cc: vbraun Merged in: sage-4.7.1.alpha1
Authors: Andrey Novoseltsev Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #10140 Stopgaps:

Status badges

Description (last modified by vbraun)

The attached patch adds preimage_fan(cone) and kernel_fan methods to FanMorphism class.

Apply trac_10882_kernel_fan.patch

Attachments (1)

trac_10882_kernel_fan.patch (6.3 KB) - added by novoselt 11 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 11 years ago by novoselt

  • Status changed from new to needs_work
  • Work issues set to degenerate cases

Hi Volker,

The patch is quite easy, as preimage_cones were already implemented, but in order to make everything shiny it would be nice to improve handling of degenerate cases. For this I need to resolve the situation with trivial fans, namely: is an empty set a fan, or it must include at least the origin? Fulton and Cox-Little-Schenck don't mention it explicitly, but from the point of view of nice correspondence to toric varieties it seems that completely empty fans should be prohibited as they seem to correspond to empty varieties, but then they don't really contain a torus.

Right now it is possible in Sage to create a fan without cones, I propose to automatically add the origin of the provided lattice in this case and treat it as the generating cone. Any objections?

Regarding preimage_fans(cone) it would imply that usually it is generated by preimage_cones(cone), but some of them maybe unnecessary for generation (e.g. in the case of blow-up, described in the documentation), i.e. generating cones of preimage_fan(cone) are a subset of preimage_cones(cone). However, if preimage_cones(cone) is empty, then preimage_fan(cone) will have an "extra" generating cone, namely the origin.

comment:2 Changed 11 years ago by novoselt

  • Work issues degenerate cases deleted

After some thinking, I have decided to make kernel_fan live in the kernel sublattice. The drawback is that currently sublattices don't work extremely well as ambient ones for cones and fans, but that should eventually change. I have made some changes improving the situation, but dual objects still don't work and so one cannot ask for cones of this kernel fan (the doctest is marked as not tested). I propose to include it nevertheless, since the constructed fan is still correct and will be completely functional once other part are improved. (And the "old" version is still available as explicit preimage_fan of the origin.)

I have also tweaked the fan constructor a little to ensure adding at least the origin cone and allowing one to specify the fan lattice which is different then cone lattices, as long as it is possible to do the conversion:

sage: P2 = toric_varieties.P2()
sage: f =
sage: f
Rational polyhedral fan in 2-d lattice N
sage: Fan(f.generating_cones())                             
Rational polyhedral fan in 2-d lattice N
sage: Fan(f.generating_cones(), lattice=f.lattice().dual())
Rational polyhedral fan in 2-d lattice M

If the lattice is not given explicitly, no conversion will be made and all cones must belong to the same lattice. But giving the lattice explicitly may be quite handy for switching between lattices/sublattices/quotients and the above example with "switching to dual" is sometimes used when one wants to compare fans of polar polytopes and think of them as fans in the same lattice.

Ready for review!

comment:3 Changed 11 years ago by novoselt

  • Status changed from needs_work to needs_review

Seems to apply cleanly on Sage-4.6.2 without anything else.

comment:4 Changed 11 years ago by novoselt

  • Status changed from needs_review to needs_info

I am having second thoughts about preimage fans: shouldn't they be full fans that are mapped into a given cone? Rather then be generated by cones whose relative interior is mapped into the relative interior of the given one. I am convinced now that preimage_cones does the correct thing, but for preimage_fan it seems a bit weird.

The reason why I didn't think enough about it before is that for the moment I only needed the kernel fan where both approaches give the same result.

comment:5 Changed 11 years ago by novoselt

  • Dependencies set to #10140
  • Status changed from needs_info to needs_review

Rebased the patch on top of new PPL interface and implemented the change in the above comment: the preimage fan consists of all cones mapped into the given one, no matter whether they are its preimage cones or not. Ready for review once again!

Changed 11 years ago by novoselt

comment:6 Changed 11 years ago by vbraun

  • Milestone changed from sage-4.7 to sage-4.7.1
  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

I agree with the definitions. Looks good to me!

comment:7 Changed 11 years ago by vbraun

  • Description modified (diff)

comment:8 Changed 11 years ago by jdemeyer

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