Sage: Ticket #12892: Toric fibration morphisms
https://trac.sagemath.org/ticket/12892
<p>
This ticket provides more morphisms that are associated to toric varieties:
</p>
<ul><li>embedding of an orbit closure
</li><li>embedding of a fiber of a toric morphism
</li><li>pull-back of divisors
</li></ul><p>
Use the git branch!
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12892
Trac 1.2Volker BraunMon, 30 Apr 2012 21:59:27 GMTstatus, description changed; cc, author set
https://trac.sagemath.org/ticket/12892#comment:1
https://trac.sagemath.org/ticket/12892#comment:1
<ul>
<li><strong>cc</strong>
<em>Andrey Novoseltsev</em> added
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12892?action=diff&version=1">diff</a>)
</li>
<li><strong>author</strong>
set to <em>Volker Braun</em>
</li>
</ul>
TicketAndrey NovoseltsevWed, 02 May 2012 16:43:16 GMTreviewer set
https://trac.sagemath.org/ticket/12892#comment:2
https://trac.sagemath.org/ticket/12892#comment:2
<ul>
<li><strong>reviewer</strong>
set to <em>Andrey Novoseltsev</em>
</li>
</ul>
<p>
This looks very cool, I plan to go over details in a couple weeks or sooner.
</p>
TicketVolker BraunWed, 02 May 2012 17:23:27 GMT
https://trac.sagemath.org/ticket/12892#comment:3
https://trac.sagemath.org/ticket/12892#comment:3
<p>
In 3 weeks we can also talk about it in person in Seattle :-)
</p>
TicketAndrey NovoseltsevFri, 18 May 2012 22:30:09 GMTdependencies set
https://trac.sagemath.org/ticket/12892#comment:4
https://trac.sagemath.org/ticket/12892#comment:4
<ul>
<li><strong>dependencies</strong>
set to <em>#12361</em>
</li>
</ul>
TicketAndrey NovoseltsevThu, 24 May 2012 17:03:22 GMT
https://trac.sagemath.org/ticket/12892#comment:5
https://trac.sagemath.org/ticket/12892#comment:5
<p>
I find the first patch a bit difficult to understand due to mixing several things defining the embedding: a cone and two dictionaries of rays. Also <code>defining_cone</code> argument is not documented in the constructor of the orbit morphism.
</p>
<p>
Orbits are in 1:1 correspondence with cones of the original fan, so it makes perfect sense to pass this information and store it (as it is currently done in the patch).
</p>
<p>
Mathematically, this is all that is needed, but since we have so far issues with supporting quotient lattices and instead the fan of the orbit lives in a "regular lattice", we need to keep the correspondence somehow. As it is done by some matrix, perhaps that's what we need to pass to the constructor and store.
</p>
<p>
Instead, the current version constructs a codomain_ray->domain_ray dictionary, it is passed to the constructor and constructor reverses it into domain_ray->codomain_index dictionary. Note that the map does not have to be one-to-one for non-simplicial fans, so this dictionary just picks some random representative for a domain ray. The choice may affect the decision on whether embedding can be realized as a polynomial map or not.
</p>
<p>
I also think it is confusing to store non-primitive generators for rays and treat a ray as not found if a non-primitive generator is found. We do represent rays throughout the code just by their generators, but it is always assumed that they are normalized.
</p>
<p>
As a feature request it would be nice to have support for maps given by homogeneous polynomials in the other direction, i.e. a map from the 12 orbit of P112 to P1 can be given as (0:z1:z2) -> (z1<sup>2:z2) and this will work for all orbits with powers corresponding to that "non-primitivity of generators". Or is it already implemented and I am missing something?
</sup></p>
<p>
Anyway, concretely: how about passing and storing <code>defining_cone</code> and <code>projection_matrix</code> as base pieces of data and relying on them for consecutive computations?
</p>
TicketAndrey NovoseltsevThu, 24 May 2012 17:10:03 GMT
https://trac.sagemath.org/ticket/12892#comment:6
https://trac.sagemath.org/ticket/12892#comment:6
<p>
For the patchbot (which should read the description...)
</p>
<p>
Apply trac_12892_orbit_closure_morphism.patch, trac_12892_toric_morphism_fibers.patch, trac_12892_toric_morphism_divisors.patch
</p>
TicketVolker BraunFri, 25 May 2012 03:17:13 GMT
https://trac.sagemath.org/ticket/12892#comment:7
https://trac.sagemath.org/ticket/12892#comment:7
<p>
As discussed with Andrey, the existence of polynomial map doesn't depend on the choices made.
</p>
<p>
Updated patch to add some clarifications.
</p>
TicketVolker BraunFri, 25 May 2012 04:32:05 GMTkeywords set
https://trac.sagemath.org/ticket/12892#comment:8
https://trac.sagemath.org/ticket/12892#comment:8
<ul>
<li><strong>keywords</strong>
<em>sd40.5</em> added
</li>
</ul>
TicketAndrey NovoseltsevFri, 25 May 2012 17:04:22 GMT
https://trac.sagemath.org/ticket/12892#comment:9
https://trac.sagemath.org/ticket/12892#comment:9
<p>
OK to the first patch!
</p>
TicketAndrey NovoseltsevSun, 27 May 2012 19:00:57 GMT
https://trac.sagemath.org/ticket/12892#comment:10
https://trac.sagemath.org/ticket/12892#comment:10
<p>
For the second patch:
</p>
<ol><li><code>relative_star_generators</code> does not have INPUT/OUTPUT and in general it would be nice to have a clear description of what it does.
</li><li>Can we please rename <code>fiber</code> to <code>generic_fiber</code>? (I would expect that <code>fiber</code> would return a particular one based on some input.) Also - why the documentation says that it returns a connected component, isn't it unique for a generic fiber?
</li><li>I also got confused by <code>fiber_component</code> name thinking it computes the fiber over points corresponding to higher-dimensional cones of the codomain. After some more thinking and reading I think that it is indeed the correct name, but would be nice to describe in the documentation the structure of non-generic fibers and why it makes more sense to work with components corresponding to domain cones rather than fibers of codomain ones.
</li><li><code>fiber_component</code> and <code>fiber_dimension</code> also lack INPUT/OUTPUT blocks.
</li><li><code>SchemeMorphism_fan_fiber_toric_variety</code> input documentation does not match the code.
</li><li>Perhaps the name of the class can be changed to <code>..._fiber_component_...</code> since it does not operate with the whole fiber.
</li><li>"Defined by embedding the fiber irreducible component defined by the primitive preimage cone 1-d cone of Rational polyhedral fan in 4-d lattice N." does not read. While I was trying to reformulate it, I became unsure of this class at all. Isn't it just about embedding a torus orbit closure into the original toric variety? I.e. the toric morphism and fibers are not important?
</li></ol>
TicketAndrey NovoseltsevSun, 27 May 2012 20:23:57 GMTstatus, dependencies changed; work_issues set
https://trac.sagemath.org/ticket/12892#comment:11
https://trac.sagemath.org/ticket/12892#comment:11
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>dependencies</strong>
changed from <em>#12361</em> to <em>#12361, #13023</em>
</li>
<li><strong>work_issues</strong>
set to <em>comments and rebasing</em>
</li>
</ul>
TicketVolker BraunSun, 27 May 2012 23:48:29 GMTattachment set
https://trac.sagemath.org/ticket/12892
https://trac.sagemath.org/ticket/12892
<ul>
<li><strong>attachment</strong>
set to <em>trac_12892_orbit_closure_morphism.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketVolker BraunMon, 28 May 2012 00:01:28 GMT
https://trac.sagemath.org/ticket/12892#comment:12
https://trac.sagemath.org/ticket/12892#comment:12
<p>
I've updated the paths for <a class="closed ticket" href="https://trac.sagemath.org/ticket/13023" title="#13023: enhancement: Move toric varieties to a dedicated folder (closed: fixed)">#13023</a>, and checked that all doctests pass.
</p>
TicketAndrey NovoseltsevTue, 05 Jun 2012 14:15:04 GMTdescription changed
https://trac.sagemath.org/ticket/12892#comment:13
https://trac.sagemath.org/ticket/12892#comment:13
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12892?action=diff&version=13">diff</a>)
</li>
</ul>
<p>
Beginning of the reviewer patch: I changed <code>fiber</code> to <code>fiber_generic</code> and want to change <code>fiber_component</code> to something more accurate since it does not necessarily return an irreducible component of a fiber, but perhaps a smaller dimensional piece. How about <code>fiber_orbit_closure</code>? That's how the documentation describes the output anyway.
</p>
TicketAndrey NovoseltsevSun, 10 Jun 2012 08:02:14 GMT
https://trac.sagemath.org/ticket/12892#comment:14
https://trac.sagemath.org/ticket/12892#comment:14
<pre class="wiki">sage: P1 = toric_varieties.P1()
sage: f = P1.hom(matrix([2]), P1)
sage: f.fiber_orbit_closure(P1.fan(1)[0])
Traceback (most recent call last):
...
ArithmeticError: Argument gens (= [(1/2)]) does not generate a submodule of self.
</pre><p>
This should either give a meaningful error message or better yet just work. I'll try to take care of it.
</p>
TicketVolker BraunWed, 27 Jun 2012 14:33:27 GMT
https://trac.sagemath.org/ticket/12892#comment:15
https://trac.sagemath.org/ticket/12892#comment:15
<p>
The problem is of course that <code>z |-> z^2</code> has two points as the fiber over {+1}. This is called the index in Hu-Liu-Yau. So we can either
</p>
<blockquote>
<p>
a) Ignore it and just return one irreducible component
</p>
</blockquote>
<blockquote>
<p>
b) Return a pair <code>(toric variety, index)</code>
</p>
</blockquote>
<blockquote>
<p>
c) Return the different connected components <code>(fiber, fiber, ..., fiber)</code>. Note that the embedding map differs by some roots of unity so you may not be able to write it over QQ...
</p>
</blockquote>
TicketAndrey NovoseltsevWed, 27 Jun 2012 16:31:28 GMT
https://trac.sagemath.org/ticket/12892#comment:16
https://trac.sagemath.org/ticket/12892#comment:16
<p>
Yeap, I am working on it - had to brush up the math definitions and then a non-trivial random example exposed some issues with current code which I am fixing. Regarding returned values, I didn't make up my mind yet, but just ignoring other components is a bad choice, I think - even if we return only one there should be another method that will return their number (and I almost have it working, I think).
</p>
TicketVolker BraunThu, 28 Jun 2012 13:27:58 GMT
https://trac.sagemath.org/ticket/12892#comment:17
https://trac.sagemath.org/ticket/12892#comment:17
<p>
Thinking about it, returning a pair <code>(fiber, index)</code> or perhaps a dict seems like the best choice. Having to call another method to get the index isn't easy to discover.
</p>
TicketAndrey NovoseltsevThu, 19 Jul 2012 05:18:32 GMT
https://trac.sagemath.org/ticket/12892#comment:18
https://trac.sagemath.org/ticket/12892#comment:18
<p>
There were failures due to the switch to <code>PointCollection</code>, I've fixed them (added <code>__add__</code>).
</p>
<p>
How about the following?
</p>
<ul><li><code>fiber_generic()</code> returns (X, N) where X is a toric variety corresponding to the kernel fan and N is the number of copies if the whole torus of the codomain is covered surjectively and 0 otherwise.
</li><li><code>fiber_component(domain_cone)</code> returns (X, N) where N is always some positive number of copies, since here we specify a domain cone and there are definitely some components corresponding to it, in particular <code>fiber_component(domain_origin)</code> will return the number of components of the fiber over distinguished point of the <code>codomain_origin</code>, even if <code>fiber_generic</code> returns (X, 0), meaning that over non-distinguished points there are likely empty fibers.
</li><li><code>fiber_dimension(codomain_cone)</code> returns -1 (or -intinity?) if the corresponding orbit of the codomain is not covered surjectively.
</li><li><code>fiber_graph(codomain_cone)</code> returns an empty graph is the corresponding orbit is not covered surjectively.
</li></ul>
TicketAndrey NovoseltsevThu, 19 Jul 2012 05:22:57 GMTattachment set
https://trac.sagemath.org/ticket/12892
https://trac.sagemath.org/ticket/12892
<ul>
<li><strong>attachment</strong>
set to <em>trac_12892_reviewer.patch</em>
</li>
</ul>
TicketVolker BraunFri, 20 Jul 2012 03:17:39 GMT
https://trac.sagemath.org/ticket/12892#comment:19
https://trac.sagemath.org/ticket/12892#comment:19
<p>
I (still) think its unwieldy to try to support non-surjective "fibrations". A fibration is a surjective morphism, otherwise its useless to describe "fibers" fitting into some familiy parametrized by the base. Its would be much easier to just raise some error in <code>fiber_...()</code> methods if the morphism is not surjective.
</p>
<p>
It seems like there is a natural way to factor a morphism into a surjection and an injection, first map to the image fan and then embed the image in the codomain. The error raised in the <code>fiber_...()</code> methods could direct the users then to do this.
</p>
TicketAndrey NovoseltsevFri, 20 Jul 2012 03:52:04 GMT
https://trac.sagemath.org/ticket/12892#comment:20
https://trac.sagemath.org/ticket/12892#comment:20
<p>
Well, what exactly do you mean by "fibration"? Fiber bundle? Fibration in the sense of <code>is_fibration</code> with all fibers having the same dimension? That excludes even blowups. Anything surjective? That excludes e.g. chart inclusion, or maps from charts of blowups into the original variety. I think for any morphism it is reasonable to look at fibers over any point of the codomain, it is just the inverse image. And whether we return something special or raise an exception, we still have to do the work of figuring out what's going on.
</p>
<p>
From the user point of view, I think it is a bit easier/more elegant to handle "corner case" outputs than exceptions, <code>fiber_component</code> and <code>fiber_dimension</code> have pretty clear meaning in general. I think <code>fiber_generic</code> has it as well. The <code>fiber_graph</code> one is indeed quite special and maybe it makes sense to restrict it to surjective or even <code>is_fibration</code> case.
</p>
<p>
In the case of factoring through the image, the middle variety can be difficult to work with and I am not even sure if the current support is sufficient for any work as well. Then again for the inclusion there is a question of what is covered and what is not, and the natural test seems to be - are there points of this point or not, but if fiber methods don't work, then there should be something separate. I think it will be more complicated.
</p>
<p>
E.g. take a blowup of a plane and consider the map from one of the charts to the plane. How will it factor??? I suspect clear factorization into surjection and injection requires working with complete fans and that's definitely way too restrictive.
</p>
TicketAndrey NovoseltsevFri, 20 Jul 2012 14:19:58 GMT
https://trac.sagemath.org/ticket/12892#comment:21
https://trac.sagemath.org/ticket/12892#comment:21
<p>
Thinking some more about the last example (which I think we should support for sure): am I right that the image is a toric variety, but not normal, so there is no fan corresponding to it? As I just checked, <code>restrict_to_image</code> so far is a method of fan morphisms only and using it here does nothing. I think this has to be the case, but the documentation should be clarified as the restriction does not have to be surjective. It kind of contradicts the name though, should we rename it? I think it is <code>restrict_to_image_closure</code> inside of the codomain. We can rename the current method to it and then have <code>restrict_to_image</code> which will do the same, but then check that the result is surjective and <code>raise ValueError</code> otherwise since "proper image restriction" is no longer a fan morphism.
</p>
TicketVolker BraunFri, 20 Jul 2012 15:14:15 GMT
https://trac.sagemath.org/ticket/12892#comment:22
https://trac.sagemath.org/ticket/12892#comment:22
<p>
There isn't really a universally accepted definition of "fibration", it depends on the category you are in. In algebraic topology it is a morphism with the homotopy lifting property, but in algebraic geometry the underlying topological space of a fibration usually is not a fibration in the topology sense. As another data point, <a class="ext-link" href="http://books.google.com/books?id=ZhzXJHUgcRUC&lpg=PA137&ots=aWMqiSqste&dq=fibration%20of%20curves&pg=PA137#v=onepage&q=fibration%20of%20curves&f=false"><span class="icon"></span>Danilov&Shafarevich define a fibration of curves</a> to be onto.
</p>
<p>
Also, <em>elliptic fibration</em> definitely implies surjective to me. Or, in other words, if you excise complete preimages in the codomain then this is not what I would call an elliptic fibration. Though of course YMMV.
</p>
<p>
Regardless of the category, I think "fibration" ought to mean that one is not dealing with the most general morphism but with a suitable morphism such that the preimages can be thought of as being parametrized by the base. To me, this means that you definitely want the morphism to be surjective or at least dominant.
</p>
<p>
In algebraic geometry, a fibration needs not be equidimensional (or <em>flat</em> in the sense of commutative algebra). This is different from the topologist's fibrations.
</p>
TicketAndrey NovoseltsevFri, 20 Jul 2012 15:50:05 GMT
https://trac.sagemath.org/ticket/12892#comment:23
https://trac.sagemath.org/ticket/12892#comment:23
<p>
Well, I guess what I suggest boils down to:
</p>
<ul><li><em>fibration</em> - a surjective equidimensional morphism, a "global in codomain" property check by <code>is_fibration</code>;
</li><li><em>fiber</em> - a preimage of a single point, a "local in codomain" construction well-defined for any morphism, regardless of its relation to fibrations in any category. <a class="ext-link" href="http://mathworld.wolfram.com/Fiber.html"><span class="icon"></span>http://mathworld.wolfram.com/Fiber.html</a> is an easy to find reference, although not as authoritative as Danilov&Shafarevich ;-)
</li></ul><p>
Maybe it is a bit unfortunate that they have the same root, kind of like reduced/reducible, but calling it <code>preimage_component(domain_cone)</code> is not clear enough since then it may mean full preimage of an orbit or its closure, and something like <code>point_preimage_component(domain_cone)</code> is incomprehensible. Limiting to surjective morphisms and excluding a morphism from a blowup chart just because of vocabulary issues is a bit unsatisfactory...
</p>
TicketVolker BraunFri, 20 Jul 2012 17:08:10 GMT
https://trac.sagemath.org/ticket/12892#comment:24
https://trac.sagemath.org/ticket/12892#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12892#comment:20" title="Comment 20">novoselt</a>:
</p>
<blockquote class="citation">
<p>
E.g. take a blowup of a plane and consider the map from one of the charts to the plane. How will it factor???
</p>
</blockquote>
<p>
I don't understand what the problem is. This should factor into the inclusion of the one chart in the blow-up (injective), and the blow-down morphism (surjective). That is:
</p>
<pre class="wiki">Fan([ Cone([(1,0),(1,1)]) ])
->
Fan([ Cone([(1,0),(1,1)]), Cone([(1,1),(0,1)]) ])
->
Fan([ Cone([(1,0),(0,1)]) ])
</pre>
TicketAndrey NovoseltsevFri, 20 Jul 2012 17:23:42 GMT
https://trac.sagemath.org/ticket/12892#comment:25
https://trac.sagemath.org/ticket/12892#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12892#comment:19" title="Comment 19">vbraun</a>:
</p>
<blockquote class="citation">
<p>
It seems like there is a natural way to factor a morphism into a surjection and an injection, first map to the image fan and then embed the image in the codomain.
</p>
</blockquote>
<p>
That's what you have suggested earlier and this is also the factorization used in HLY paper. The intermediate variety is clearly defined: intersect the codomain fan with the linear subspace spanned by the map of lattices. Works fine when both fans of domain/codomain are complete.
</p>
<p>
Now for the blowup chart you propose to replace a map between two affine varieties induced by the identity matrix with a reverse factorization - first inclusion, then surjection, going through an intermediate non-affine variety. How is this intermediate variety defined/constructed in general?
</p>
TicketVolker BraunThu, 21 Mar 2013 11:35:10 GMT
https://trac.sagemath.org/ticket/12892#comment:26
https://trac.sagemath.org/ticket/12892#comment:26
<p>
Sorry for the long hiatus, but I'm ready to finish this ticket now.
</p>
<p>
I think the problem is a question of language, the HLY factorization is into a surjective map and one that is generically injective (but not necessarily everywhere if the domain fan is not complete). So thats fine, we'll implement this factorization and then attach the functionaly of this ticket to the surjective fan morphisms. Do you agree?
</p>
TicketVolker BraunSun, 24 Mar 2013 22:35:25 GMTdependencies changed
https://trac.sagemath.org/ticket/12892#comment:27
https://trac.sagemath.org/ticket/12892#comment:27
<ul>
<li><strong>dependencies</strong>
changed from <em>#12361, #13023</em> to <em>#12361, #13023, #14353</em>
</li>
</ul>
<p>
The factoring part is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/14353" title="#14353: enhancement: Factor toric morphism into surjective and generically injective (closed: fixed)">#14353</a>
</p>
TicketAndrey NovoseltsevMon, 25 Mar 2013 05:01:18 GMT
https://trac.sagemath.org/ticket/12892#comment:28
https://trac.sagemath.org/ticket/12892#comment:28
<p>
I'm the one who should be sorry for delays and dragging tickets ;-) I need to go over the discussion here and patches again as I remember confusing myself half a year ago while doing and undoing changes in my patch.
</p>
<p>
This factorization makes sense: first to the fan of images of cones in the image sublattice, then inclusion of this fan by the identity map, which is certainly injective on the torus, but may not be on the lower dimensional orbits. I'll try to get back with more detailed thoughts on Tuesday or, at worst, next weekend.
</p>
TicketAndrey NovoseltsevTue, 02 Apr 2013 06:00:50 GMT
https://trac.sagemath.org/ticket/12892#comment:29
https://trac.sagemath.org/ticket/12892#comment:29
<p>
OK, just before the long weekend is over: I still would like to have methods for fibers work in non-surjective case, but with surjective/generically-injective factorization it certainly does not have to be the default and perhaps can be turned on by some parameter like <code>over_distinguished_point=True</code> which can then add extra output components as well.
</p>
TicketVolker BraunTue, 02 Apr 2013 21:28:06 GMT
https://trac.sagemath.org/ticket/12892#comment:30
https://trac.sagemath.org/ticket/12892#comment:30
<p>
My plan was to move all fibration-related stuff into a subclass for surjective toric morphisms. That'll allow us to have a simple interface for fibrations. This avoids the whole issue of selecting different fibers over various strata of the torus orbits in the codomain, which is encoded in the non-surjective part of the factored morphism.
</p>
TicketVolker BraunMon, 24 Jun 2013 00:19:54 GMTattachment set
https://trac.sagemath.org/ticket/12892
https://trac.sagemath.org/ticket/12892
<ul>
<li><strong>attachment</strong>
set to <em>trac_12892_toric_morphism_divisors.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketVolker BraunMon, 24 Jun 2013 00:20:09 GMTattachment set
https://trac.sagemath.org/ticket/12892
https://trac.sagemath.org/ticket/12892
<ul>
<li><strong>attachment</strong>
set to <em>trac_12892_toric_morphism_fibers.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketVolker BraunMon, 24 Jun 2013 00:20:24 GMT
https://trac.sagemath.org/ticket/12892#comment:31
https://trac.sagemath.org/ticket/12892#comment:31
<p>
Rediffed for sage-5.11.beta3
</p>
TicketAndrey NovoseltsevSun, 30 Jun 2013 18:54:31 GMT
https://trac.sagemath.org/ticket/12892#comment:32
https://trac.sagemath.org/ticket/12892#comment:32
<p>
How about this compromise between surjective/general morphisms support - compute fibers only for dominant ones. For a toric morphism being dominant implies:
</p>
<ul><li>surjection between tori, thus
</li><li>surjection onto any torus orbit if it was hit at all, so
</li><li>fiber/preimage over any point of any orbit is the same, including the case when it is empty.
</li></ul><p>
So there is no confusion with returning something when distinguished points have something over them and some others don't. In terms of <a class="closed ticket" href="https://trac.sagemath.org/ticket/14353" title="#14353: enhancement: Factor toric morphism into surjective and generically injective (closed: fixed)">#14353</a> factorization, this means supporting compositions of surjective and birational factors, but throwing exceptions if the last injective factor is not an identity map on tori/lattices.
</p>
<p>
In particular, a blowup chart will be supported with single point fiber over the torus, single point fiber over one of the axis, empty fiber over another axis, and an affine line fiber over the origin. Awesome example for some intro classes ;-)
</p>
TicketAndrey NovoseltsevMon, 15 Jul 2013 22:31:51 GMT
https://trac.sagemath.org/ticket/12892#comment:33
https://trac.sagemath.org/ticket/12892#comment:33
<p>
There is some fuzz for the first patch on 5-11.beta3:
</p>
<pre class="wiki">novoselt@sage:~/sage/devel/sage$ hg qseries
trac_14210_matrix_mpolynomial_dense.patch
trac_14210_reviewer.patch
trac_13458_toric_Weierstrass_covering.patch
trac_13458_reviewer.patch
trac_12892_orbit_closure_morphism.patch
trac_12892_toric_morphism_fibers.patch
trac_12892_toric_morphism_divisors.patch
novoselt@sage:~/sage/devel/sage$ hg qgoto ism_div
applying trac_14210_matrix_mpolynomial_dense.patch
applying trac_14210_reviewer.patch
applying trac_13458_toric_Weierstrass_covering.patch
applying trac_13458_reviewer.patch
applying trac_12892_orbit_closure_morphism.patch
patching file sage/schemes/toric/morphism.py
Hunk #2 succeeded at 348 with fuzz 2 (offset 8 lines).
applying trac_12892_toric_morphism_fibers.patch
applying trac_12892_toric_morphism_divisors.patch
now at: trac_12892_toric_morphism_divisors.patch
</pre>
TicketAndrey NovoseltsevMon, 15 Jul 2013 23:43:53 GMT
https://trac.sagemath.org/ticket/12892#comment:34
https://trac.sagemath.org/ticket/12892#comment:34
<p>
And somehow these patches break fresh factoring: 3 failures with <code>AttributeError: 'SchemeMorphism_fan_toric_variety' object has no attribute 'is_birational'</code>
</p>
TicketVolker BraunSun, 21 Jul 2013 04:24:02 GMTdescription, work_issues changed; branch set
https://trac.sagemath.org/ticket/12892#comment:35
https://trac.sagemath.org/ticket/12892#comment:35
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12892?action=diff&version=35">diff</a>)
</li>
<li><strong>branch</strong>
set to <em>u/vbraun/toric_fibration</em>
</li>
<li><strong>work_issues</strong>
changed from <em>comments and rebasing</em> to <em>comments</em>
</li>
</ul>
<p>
I moved the patches into a git branch and cleaned up the doctest errors (e.g. <code>is_birational</code> was only defined for the fan morphism, not the scheme morphism).
</p>
TicketAndrey NovoseltsevSun, 21 Jul 2013 05:01:28 GMT
https://trac.sagemath.org/ticket/12892#comment:36
https://trac.sagemath.org/ticket/12892#comment:36
<p>
Do we already have instructions somewhere on how to work with these branches?
</p>
TicketVolker BraunSun, 21 Jul 2013 05:42:06 GMT
https://trac.sagemath.org/ticket/12892#comment:37
https://trac.sagemath.org/ticket/12892#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12892#comment:36" title="Comment 36">novoselt</a>:
</p>
<blockquote class="citation">
<p>
Do we already have instructions somewhere on how to work with these branches?
</p>
</blockquote>
<p>
Working on it at <a class="closed ticket" href="https://trac.sagemath.org/ticket/14481" title="#14481: task: document the new workflow (closed: fixed)">#14481</a>
</p>
TicketVolker BraunTue, 06 Aug 2013 20:33:40 GMTstatus changed
https://trac.sagemath.org/ticket/12892#comment:38
https://trac.sagemath.org/ticket/12892#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I've updated the branch to implement <code>is_dominant</code>, a subclass of dominant toric morphisms, and moved the fibration methods there. Also, a subsection in the documentation to expand on your example of the blowup chart.
</p>
TicketJeroen DemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/12892#comment:39
https://trac.sagemath.org/ticket/12892#comment:39
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketJeroen DemeyerMon, 19 Aug 2013 06:34:24 GMTmilestone changed
https://trac.sagemath.org/ticket/12892#comment:40
https://trac.sagemath.org/ticket/12892#comment:40
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.12</em> to <em>sage-6.0</em>
</li>
</ul>
TicketgitMon, 02 Sep 2013 10:15:44 GMTcommit set
https://trac.sagemath.org/ticket/12892#comment:41
https://trac.sagemath.org/ticket/12892#comment:41
<ul>
<li><strong>commit</strong>
set to <em>c3357583cf90021b906c52e635a9b9793e9234c9</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:c335758]</td><td>resolved conflict with Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/14891" title="#14891: enhancement: Counting points on a toric variety over a finite field (closed: fixed)">#14891</a>
</td></tr></table>
TicketAndrey NovoseltsevTue, 24 Sep 2013 16:44:59 GMT
https://trac.sagemath.org/ticket/12892#comment:42
https://trac.sagemath.org/ticket/12892#comment:42
<p>
Will change return format to <code>(fiber_component, index)</code> to play with git.
</p>
TicketJan KeitelTue, 24 Sep 2013 17:02:26 GMTcc changed
https://trac.sagemath.org/ticket/12892#comment:43
https://trac.sagemath.org/ticket/12892#comment:43
<ul>
<li><strong>cc</strong>
<em>Jan Keitel</em> added
</li>
</ul>
TicketAndrey NovoseltsevWed, 25 Sep 2013 11:32:34 GMTbranch changed
https://trac.sagemath.org/ticket/12892#comment:44
https://trac.sagemath.org/ticket/12892#comment:44
<ul>
<li><strong>branch</strong>
changed from <em>u/vbraun/toric_fibration</em> to <em>u/novoselt/toric_fibration</em>
</li>
</ul>
TicketgitWed, 25 Sep 2013 11:33:11 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:45
https://trac.sagemath.org/ticket/12892#comment:45
<ul>
<li><strong>commit</strong>
changed from <em>c3357583cf90021b906c52e635a9b9793e9234c9</em> to <em>f0aedcd605f8328e7e77ed633e72f57f106aeae1</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:f0aedcd]</td><td>Make fiber_generic return component count, doctests not adjusted yet.
</td></tr><tr><td>[changeset:c335758]</td><td>resolved conflict with Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/14891" title="#14891: enhancement: Counting points on a toric variety over a finite field (closed: fixed)">#14891</a>
</td></tr><tr><td>[changeset:19e832a]</td><td>Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/12892" title="#12892: enhancement: Toric fibration morphisms (closed: fixed)">#12892</a>: Move fibration methods to subclass of dominant morphisms
</td></tr><tr><td>[changeset:1142feb]</td><td>Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/12892" title="#12892: enhancement: Toric fibration morphisms (closed: fixed)">#12892</a>: Reviewer changes to toric morphisms.
</td></tr><tr><td>[changeset:78dc617]</td><td>Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/12892" title="#12892: enhancement: Toric fibration morphisms (closed: fixed)">#12892</a>: Pull back toric divisors via toric morphisms
</td></tr><tr><td>[changeset:7fb4df5]</td><td>Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/12892" title="#12892: enhancement: Toric fibration morphisms (closed: fixed)">#12892</a>: Toric fibration fiber
</td></tr><tr><td>[changeset:9aa485f]</td><td>Trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/12892" title="#12892: enhancement: Toric fibration morphisms (closed: fixed)">#12892</a>: Toric fibration morphisms
</td></tr></table>
TicketgitThu, 26 Sep 2013 18:12:23 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:46
https://trac.sagemath.org/ticket/12892#comment:46
<ul>
<li><strong>commit</strong>
changed from <em>f0aedcd605f8328e7e77ed633e72f57f106aeae1</em> to <em>363f57b548841f4d272bf8417fb114b6509324d0</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:363f57b]</td><td>Doctests pass, still looking at code.
</td></tr></table>
TicketgitFri, 27 Sep 2013 17:18:19 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:47
https://trac.sagemath.org/ticket/12892#comment:47
<ul>
<li><strong>commit</strong>
changed from <em>363f57b548841f4d272bf8417fb114b6509324d0</em> to <em>943e71bbe836b097875746717b0621e5ac04e120</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:943e71b]</td><td>Use span instead of submodule to deal with rational preimages
</td></tr><tr><td>[changeset:1949102]</td><td>Throw <a class="missing wiki">ValueError?</a> instead of <a class="missing wiki">TypeError?</a> for complicated morphisms.
</td></tr></table>
TicketAndrey NovoseltsevFri, 27 Sep 2013 17:22:32 GMT
https://trac.sagemath.org/ticket/12892#comment:48
https://trac.sagemath.org/ticket/12892#comment:48
<p>
Made <a class="ticket" href="https://trac.sagemath.org/ticket/12892#comment:14" title="Comment 14">square map</a> work. Also tried to use quotient lattices more but without much success.
</p>
<p>
What exactly is <code>_image_ray_multiplicity</code> mathematically? I am confused by picking the maximum one - why don't other matter?
</p>
TicketgitSat, 28 Sep 2013 14:20:53 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:49
https://trac.sagemath.org/ticket/12892#comment:49
<ul>
<li><strong>commit</strong>
changed from <em>943e71bbe836b097875746717b0621e5ac04e120</em> to <em>6b4b318ad94b078d4eb0323d7b72a96c60e4c040</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:6b4b318]</td><td>Treat generic fiber correctly as a fiber component.
</td></tr><tr><td>[changeset:317dd40]</td><td>Fixes to deal with maps between sublattices and virtual rays.
</td></tr></table>
TicketAndrey NovoseltsevSat, 28 Sep 2013 14:27:31 GMT
https://trac.sagemath.org/ticket/12892#comment:50
https://trac.sagemath.org/ticket/12892#comment:50
<p>
Thinking of making <code>aris</code> (a variant of spelling arris, "the sharp edge or salient angle formed by the meeting of two surfaces especially in moldings") an alias for <code>ambient_ray_indices</code> ;-) Would make doctest a bit shorter.
</p>
<p>
Still have a bug in fan isomorphism and another one in representing morphisms as polynomial maps. Problems tend to stem from either fans/morphisms involving sublattices, which seem to be easy to fix, or from not dealing properly with torus factors, which are more involved.
</p>
TicketgitSat, 28 Sep 2013 16:54:48 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:51
https://trac.sagemath.org/ticket/12892#comment:51
<ul>
<li><strong>commit</strong>
changed from <em>6b4b318ad94b078d4eb0323d7b72a96c60e4c040</em> to <em>e79e8405a5c762eeaed7b6553195f6c73d561861</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td>[changeset:e79e840]</td><td>Added a long fibration example. One doctest failure due to fan isomorphism bug.
</td></tr></table>
TicketAndrey NovoseltsevSat, 28 Sep 2013 17:03:24 GMT
https://trac.sagemath.org/ticket/12892#comment:52
https://trac.sagemath.org/ticket/12892#comment:52
<p>
Jan - I think that embedding construction code here is stabilized (unless Volker has any objections) and it is OK to merge your changes on top of this.
</p>
TicketAndrey NovoseltsevSat, 28 Sep 2013 17:28:38 GMT
https://trac.sagemath.org/ticket/12892#comment:53
https://trac.sagemath.org/ticket/12892#comment:53
<p>
Volker - How about adding <code>.coordinates()</code> or something like this method to <code>PointCollection</code> which will return a point collection with the same points as the original, but written in terms of the basis of the original module? I think this will help in dealing with sublattices and quotients, e.g. there is a bunch of methods for 2d fans that test dimension of the lattice, but need to take into account that actual points may have more than 2 components. This is the reason for the failing doctest where P2 is represented by a fan in a sublattice.
</p>
TicketAndrey NovoseltsevMon, 30 Sep 2013 08:44:47 GMTkeywords, work_issues changed
https://trac.sagemath.org/ticket/12892#comment:54
https://trac.sagemath.org/ticket/12892#comment:54
<ul>
<li><strong>keywords</strong>
<em>sd53</em> added
</li>
<li><strong>work_issues</strong>
changed from <em>comments</em> to <em>fan isomorphism bug</em>
</li>
</ul>
TicketFor batch modificationsTue, 17 Dec 2013 18:39:51 GMTmilestone changed
https://trac.sagemath.org/ticket/12892#comment:55
https://trac.sagemath.org/ticket/12892#comment:55
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.0</em> to <em>sage-6.1</em>
</li>
</ul>
TicketAndrey NovoseltsevWed, 18 Dec 2013 20:24:37 GMT
https://trac.sagemath.org/ticket/12892#comment:56
https://trac.sagemath.org/ticket/12892#comment:56
<p>
Hey Volker, since you have started merging branches, I propose marking the failing doctest for P2 as known bug and merging this one as well - correct fix for P2 will require some careful work and it is certainly not introduced by this ticket. Do you have any objections to my changes so far?
</p>
TicketVolker BraunThu, 19 Dec 2013 13:18:41 GMT
https://trac.sagemath.org/ticket/12892#comment:57
https://trac.sagemath.org/ticket/12892#comment:57
<p>
I agree with your changes, thanks! I'm also fine with marking the P2 thing as known bug and split it of to a separate ticket. Please go ahead!
</p>
TicketFor batch modificationsThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/12892#comment:58
https://trac.sagemath.org/ticket/12892#comment:58
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketgitWed, 26 Mar 2014 04:24:13 GMTcommit changed
https://trac.sagemath.org/ticket/12892#comment:59
https://trac.sagemath.org/ticket/12892#comment:59
<ul>
<li><strong>commit</strong>
changed from <em>e79e8405a5c762eeaed7b6553195f6c73d561861</em> to <em>b3f06ed5bb902f1f4ce0f3f11935cf62101137d0</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=b3f06ed5bb902f1f4ce0f3f11935cf62101137d0"><span class="icon"></span>b3f06ed</a></td><td><code>Marked failing doctest as a known bug #16012.</code>
</td></tr></table>
TicketAndrey NovoseltsevWed, 26 Mar 2014 04:29:36 GMTstatus, keywords changed; work_issues deleted
https://trac.sagemath.org/ticket/12892#comment:60
https://trac.sagemath.org/ticket/12892#comment:60
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>keywords</strong>
<em>toric</em> added
</li>
<li><strong>work_issues</strong>
<em>fan isomorphism bug</em> deleted
</li>
</ul>
<p>
Hey Volker - sorry for spending 3 months on these 3 doc lines, but it is still seems to be mergeable and tests run fine for me. I'll take the liberty to switch to positive review since this change was preapproved.
</p>
TicketVolker BraunTue, 01 Apr 2014 00:11:42 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/12892#comment:61
https://trac.sagemath.org/ticket/12892#comment:61
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/novoselt/toric_fibration</em> to <em>b3f06ed5bb902f1f4ce0f3f11935cf62101137d0</em>
</li>
</ul>
Ticket