#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.

Reply via email to