#10525: move algebraic subschemes of toric varieties to their rightful places
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.6.2
Component: algebraic geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by vbraun):
* status: needs_info => needs_review
* reviewer: => Andrey Novoseltsev
Comment:
Hi Andrey,
I do understand your points and I do agree that there is a case to be made
to separate them. But at least for now I would prefer to have everything
in one place:
* Its easier to refactor things if you don't have to hunt for code in
different files. If you get confused with similar-looking methods then
that really shows that common code ought to be moved to the base class.
* From the end user point of view, there shouldn't be much of a difference
between the affine schemes. Its an ambient space with equations. The end
user is probably interested in presentation-independent properties like
irreducible components, dimensions, singularities. Not so much about the
details of the embedding. The module documentation should emphasize that
that the different classes behave in the same way and not so much focus on
the implementation details.
* Also, for "patches" of toric varieties we definitely need both the
affine toric patches as well as the embedding in affine space (with the
toric ideal). So again the different algebraic schemes end up being
coupled more tightly than you think.
* Im unifying the somewhat duplicated methods `projective_embedding` vs.
`embedding_morphism` in `trac_10540_Spec_of_affine_toric_variety.patch`.
In any case, I think we should first merge this sequence of patches and
then figure out the coercion / category framework. If we can then split
the code into different files without introducing cyclic dependencies then
I'd be happy to do so.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10525#comment:3>
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.