#9664: Graphical representation of fans
----------------------------+-----------------------------------------------
   Reporter:  vbraun        |       Owner:  mhampton  
       Type:  enhancement   |      Status:  needs_work
   Priority:  major         |   Milestone:  sage-4.6  
  Component:  geometry      |    Keywords:            
     Author:  Volker Braun  |    Upstream:  N/A       
   Reviewer:                |      Merged:            
Work_issues:                |  
----------------------------+-----------------------------------------------

Comment(by novoselt):

 Hi Volker! So, here is my plan/proposal:
  1. Make all "toric objects" plottable in a consistent way with options
 trickling down from complicated objects to simpler ones.
  1. Gather all these options in a single file, say
 `sage.geometry.toric_plot` and use this module to store default options
 with users being able to see all options, change them globally and reset
 to originals. The same options also can be passed to each individual
 object.
  1. It is totally fine to have different internal functions for 2d and 3d
 plots, but when possible options should have the same name/meaning.
  1. I like your round 2-d fans, but I think there should be 3 ways to plot
 fans (and other things): in the disk of given radius, in the box with
 given sides (i.e. xyz-dimensions), and in the polytope determined by rays,
 i.e. rays are drawn to primitive generators, and cones are drawn between
 primitive generators. Reason - I think that round plots are pretty (so
 people should use them and I propose this as default), boxed plots are
 common (so people may want to use them despite of round ones being
 prettier), and "generator plot" seems to be very natural from the point of
 view of CPR-Fano toric varieties and I think this should be the default
 for them.
  1. I think that rays should be a little longer than cones, so that arrows
 "stick out", and the length of these rays does not have to correlate with
 primitive generators (but it would be nice to mark the generators with red
 dots, or some other way to clearly distinguish them from other lattice
 points).
  1. What is the purpose of white strips surrounding rays in your
 functions? (I agree that it looks pretty ;-))

 Here are the options I think toric objects should have (each consequent
 one accepts parameters for previous ones):
  1. `ToricLatticeElement` (plots a point):
   * `point_color`
   * `point_size`
   * `point_label`
   * `point_label_shift` (so that it is not right on top of the point)
  1. `ToricLattice` (plots all points within the given region):
   * `plot_type` (one of "round", "box", "generators")
   * `radius` (for "round", can also be given for "box" as all six bounds)
   * `xyzmin/max` (six parameters)
  1. `IntegralRayCollection`:
   * `ray_color`
   * `ray_thickness`
   * `ray_extension` (how much longer should rays be compared to the size
 based on other parameters, to make "arrows sticking out")
   * `ray_label`
   * `ray_label_shift`
   * `generator_color` (for the lattice point corresponding to generator)
   * `generator_size`
   * `plot_lattice` (True/False to include lattice points or not)
  1. `Cone`
   * `cone_color`
   * `cone_alpha`
   * `cone_label`
   * maybe something to determine label position, but it seems that it can
 be position quite well between rays without necessity to shift it further
   * `plot_rays` (True/False)
   * `ray_label` can be given as a list of separate labels for each ray
 (just indexing them may be not very good, e.g. for toric varieties it may
 make sense to stick coordinate names next to rays)
  1. `Fan`
   * `plot_cones` (True/False)
   * `cone_label` can be given as a list of separate labels for each cone

 In 3-d cases there may be some sense in being able to specify options
 differently for 2-d and 3-d cones, but that should be more clear in the
 process. Also, instead of drawing points corresponding to generators,
 maybe it is better to draw vectors, as in your implementation. But I still
 would like to see rays continuing "to infinity", i.e. beyond shaded
 regions for cones.

 Thoughtscomments?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9664#comment:4>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to