Opened 2 years ago
Closed 2 years ago
#18443 closed enhancement (fixed)
Multiplier spectra for projective morphisms
Reported by:  gjorgenson  Owned by:  

Priority:  minor  Milestone:  sage6.8 
Component:  algebraic geometry  Keywords:  
Cc:  bhutz  Merged in:  
Authors:  Grayson Jorgenson  Reviewers:  Ben Hutz 
Report Upstream:  N/A  Work issues:  
Branch:  6112c29 (Commits)  Commit:  6112c29bf609d6cededc1441ffb99d75faef0893 
Dependencies:  #18409  Stopgaps: 
Description
Implement a function to compute the n multiplier spectra, the set of multipliers of periodic points of formal period n, of a projective morphism. This currently only makes sense for morphisms over projective space of dimension 1.
Change History (20)
comment:1 Changed 2 years ago by
 Branch set to u/gjorgenson/ticket/18443
 Created changed from 05/18/15 16:42:11 to 05/18/15 16:42:11
 Modified changed from 05/18/15 16:42:11 to 05/18/15 16:42:11
comment:2 Changed 2 years ago by
 Commit set to e50b845d28353d49ef546a5d23d9b324116b9cec
comment:3 Changed 2 years ago by
 Milestone changed from sage6.7 to sage6.8
 Status changed from new to needs_review
comment:4 Changed 2 years ago by
 Reviewers set to Ben Hutz
 Status changed from needs_review to needs_work
A few things here, the big one is that the multiplier spectrum is defined with multiplicities. So if a perioidic point has multiplicity > 1 its multiplier should be repeated. Such as example should be added to the doc tests.
Other minor issues:
 a positive integer, the period.
 numberfield > number field
 n = int(n)
 change_ring now works for QQbar, so this is not needed
if not PS.base_ring() is QQbar: emb = PS.base_ring().embeddings(QQbar)[0] f = self.change_ring(QQbar,embedding=emb) # to be able to find all periodic points else: f = self
 f.multiplier(P,n)[0][0] > f.multiplier(P,n)[0,0]
 multipliers.sort() > not needed
 sigma_invariants  2nd senctence should say all periodic points. (same for INPUT)
 from sage.combinat.sf.sf import SymmetricFunctions? > move to top
 make len(multipliers) a constant in for loop
comment:5 Changed 2 years ago by
 Commit changed from e50b845d28353d49ef546a5d23d9b324116b9cec to cc8b735281e6af9721a92c7850567a36574ec8c3
Branch pushed to git repo; I updated commit sha1. New commits:
cc8b735  18443: Implemented changes from review.

comment:6 Changed 2 years ago by
 Commit changed from cc8b735281e6af9721a92c7850567a36574ec8c3 to 3333f6a4115954aa3a5e3e209e35e8b104ac160a
comment:7 Changed 2 years ago by
 Status changed from needs_work to needs_review
comment:8 Changed 2 years ago by
 Status changed from needs_review to needs_work
A couple things in multiplier_spectrum
 you should check that the domain is projective space to avoid subschemes
 K = f._number_field_from_algebraics() should be outside the if
 if [1,0] is a point of multplicity you will miss this (You also only check if it is fixed not nperiodic). You could instead see if the poly F is of the form
y^m*G(x,y)
for some poly G, then m is the multplicity of [1,0].
 it doesn't seem like your conversion to QQbar is working. Trying your number field example, when the map is actually defined over a number field
sage: set_verbose(None) sage: z = QQ['z'].0 sage: K.<w> = NumberField(z^4  4*z^2 + 1) sage: P.<x,y> = ProjectiveSpace(K,1) sage: H = End(P) sage: f = H([x^2  w/4*y^2,y^2]) sage: f.multiplier_spectra(2,False)
Not sure exactly what you should do here. One option is to get change_ring for polynomials to deal with QQbar, by passing in and/or creating an embedding. If you look in schemes.generic.morphism.SchemeMorphism_polynomial.change_ring() it gives a simple way to construct a hom of polynomials given a hom of the base rings. It does appear that the change_ring of the parent is working, so you probably just need to create the hom between the poly rings and apply it to the element to be changed.
comment:9 Changed 2 years ago by
 Commit changed from 3333f6a4115954aa3a5e3e209e35e8b104ac160a to 71d1123d488ff029e34f50600554aa4fd5be32cd
Branch pushed to git repo; I updated commit sha1. New commits:
71d1123  18443: implemented changes from second review

comment:10 Changed 2 years ago by
For the formal==True case I used the technique in the morphism change_ring function to create the homomorphism between polynomial rings to use on F and this seems to have addressed the issues so far. For the formal==False case, the conversion already seemed to be working, but the _number_field_from_algebraics version of the map wasn't needed for finding roots.
I found another problem though:
P.<x,y> = ProjectiveSpace(QQ,1) H = End(P) f = H([x^2  3/4*y^2,y^2]) f.multiplier_spectra(2)
gives [1,1] back which isn't correct.
I didn’t catch this before, but multiplier_spectra should only return [1] here, because there is only one two cycle. The collapsing causes this two cycle to turn into a root of multiplicity 2 of the dynatomic polynomial, so the algorithm I use to pick representatives from cycles doesn’t work.
I will implement a fix attempt for this next, but I wanted to push up the current commit before doing so.
comment:11 Changed 2 years ago by
For x^23/4
, what you have are *no* 2cycles. There are 2 formal 2periodic points, but they are a doubled fixed point. So, I'm not sure [1,1] is incorrect in this case. Why do you think this is wrong?
comment:12 Changed 2 years ago by
I thought getting [1,1] back was messing up the resulting elementary symmetric polynomial. For the other x^2 + c
, the formal 2multiplier spectra consists of one multiplier and so there is only one elementary symmetric polynomial, sigma_{1}^{(2)} = sigma_2 + 4
. For x^2  3/4
, if we use [1,1] we have an extra multiplier, and sigma_{1}^{(2)} = 1+1 = 2
when we expect sigma_{1}^{(2)} = sigma_2 + 4 = 1
.
I was thinking that it might be better to treat the doubled fixed point as a single 2cycle so that we only get one multiplier. Would that work?
comment:13 Changed 2 years ago by
hmm...yes I see your point. I think having the correct number of multipliers so that the elementary symmetric polynomials are continuous as they are supposed to be would be the correct approach.
comment:14 Changed 2 years ago by
 Commit changed from 71d1123d488ff029e34f50600554aa4fd5be32cd to 3aca932972ebf48911a05bcfef34d248b7a33e88
Branch pushed to git repo; I updated commit sha1. New commits:
3aca932  18443: attempt to adapt algorithm for selecting cycle representatives

comment:15 Changed 2 years ago by
 Status changed from needs_work to needs_review
I modified the selection loop slightly so now there's no break when iterating points to find their cycles. I think this will address the issue of extra representative points for collapsed cycles, and shouldn't change anything for maps with no collapsing.
comment:16 Changed 2 years ago by
 Status changed from needs_review to needs_work
Just a couple very minor things here. You should actually convert n, not just check the conversion. ie. use n=int(n)
Also, I'd rather not have you accessing the ._polys list directly. Instead you can use G[0], G[1], etc.
Finally, I'd like to see an example with multiplicities.
I see you directly implemented the QQbar change ring for the dynatomic polynomial. I still think the .change_ring() should be fixed as well, but that can be done in a different ticket.
comment:17 Changed 2 years ago by
 Commit changed from 3aca932972ebf48911a05bcfef34d248b7a33e88 to 6112c29bf609d6cededc1441ffb99d75faef0893
Branch pushed to git repo; I updated commit sha1. New commits:
6112c29  18443: minor changes and new example

comment:18 Changed 2 years ago by
 Status changed from needs_work to needs_review
I added an example using x^2  7/4
which has a collapsed 3cycle. I left the x^2 3/4
example in to illustrate that the doubled fixed point is treated as one 2cycle, but I can remove it if it seems unnecessary.
comment:19 Changed 2 years ago by
 Status changed from needs_review to positive_review
comment:20 Changed 2 years ago by
 Branch changed from u/gjorgenson/ticket/18443 to 6112c29bf609d6cededc1441ffb99d75faef0893
 Resolution set to fixed
 Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. New commits:
18443: added default values to documentation