#8989: Add support for Fano toric varieties
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5
Component: algebraic geometry | Keywords:
Author: Andrey Novoseltsev | Upstream: N/A
Reviewer: Volker Braun | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_work
Comment:
1-3) I am actually having second thoughts about all these names. I think
this is basically the same issue as with `cone.N` vs.
`cone.spanned_lattice` and to avoid imposing names on users and things
like `Y = CPRFanoToricVariety(delta=X.nabla())` we should use some
"neutral but descriptive names" and then indicate how it is related to the
standard notation in documentation.
In this particular case I would prefer to replace `delta` with `polytope`
everywhere in the code. Then one can write:
{{{
sage: Delta = some polytope
sage: nabla = Delta.polar()
sage: X = CPRFanoToricVariety(Delta)
sage: Y = CPRFanoToricVariety(nabla)
sage: X.polytope() is Delta
True
sage: Y.polytope() is nabla
True
}}}
or, if one prefers other names, something like
{{{
sage: Delta = some polytope
sage: Delta_circ = Delta.polar()
sage: X = CPRFanoToricVariety(Delta)
sage: Y = CPRFanoToricVariety(Delta_circ)
sage: X.polytope() is Delta
True
sage: Y.polytope() is Delta_circ
True
}}}
Moreover, it now will be possible to have some global switch to make `X`
above correspond to the normal fan of `Delta`, rather than face one:
{{{
sage: Delta = some polytope
sage: nabla = Delta.polar()
sage: X = CPRFanoToricVariety(Delta)
sage: Y = CPRFanoToricVariety(nabla)
sage: X.polytope() is Delta.polar()
True
sage: Y.polytope() is nabla.polar()
True
}}}
Personally, I like Nill's paper, as well as his notation, and I certainly
saw some other ones with notation different from Delta in M/nabla in N. I
think our goal for Sage is to make as flexible and consistent package as
possible, suitable both for beginners and "advancers". So I do agree that
we should not enforce Nill's notation, but I also think that we should not
hard-code any other (even though I have done it so far in this patch).
Notation is always just notation, we should operate with more conceptual
things...
5) Agreed. Assuming `delta` is renamed to `polytope`, I would then prefer
`polytope_point_to_coordinate` taking either an index or an actual point
as an argument. Long, but should be quite clear.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8989#comment:11>
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.
