Closed rharron closed 11 years ago
I forgot to mention the simple solution: each element has, in addition to an ordp, an M. I've brought up this possibility a couple times for non-families, but then once I understood the "magic" that was going on, I saw that it was unnecessary because you can safely conflate the p-adic precision with the filtration precision. But for families you can't.
If we do this, we could store the zero distribution in D / Fil^M as (p^(M_c_p), M, ()), i.e. valuation p^(M_c_p), known mod Fil^M, and no moments. Similarly, an element of (p^rD) / Fil^M could be stored as (p^r, M, (a_0 mod p^(Mc_p - r), ..., a_i mod p^((M-i) * cp - r), ..., a{M-1-r} mod p^((r+1) \ c_p - r)) (where I've dropped the ceiling from the notation for legibility).
Ah! I ran into a similar problem when typing up the details of section 8.1 of our paper. The problem here is that our current filtration comes in p-1 different patterns. Namely, the required valuation typically drops by 1 as we increase the moment except for our exceptional slot (between 0 and p-2) where it stays flat. And this exceptional slot allows for p-1 different patterns.
But, I think, there is no need to do this! Why not just fix a pattern? Let's require the 0-th moment to have valuation at least N c_p and the first moment to again have valuation at least N c_p, and then start dropping for the next p-3 moments, and then repeat... This should still give a nice filtration.
Moreover, the filtration has the following nice uniform description that I was struggling with in section 8.1. Define K_0 to be the distributions whose j-th moment have valuation at least -j c_p. We then have:
p^(ceil(M c_p)) K_0 \cap D
is exactly the filtration I described above. (This description is important in dealing with distributions with infinitely many denominators.)
Would this resolve the accuracy issue you were worried about? If so, let's go with it because I like this uniform filtration better.
On Fri, Mar 29, 2013 at 11:24 AM, rharron notifications@github.com wrote:
I forgot to mention the simple solution: each element has, in addition to an ordp, an M. I've brought up this possibility a couple times for non-families, but then once I understood the "magic" that was going on, I saw that it was unnecessary because you can safely conflate the p-adic precision with the filtration precision. But for families you can't.
If we do this, we could store the zero distribution in D / Fil^M as (p^(M_c_p), M, ()), i.e. valuation p^(M_c_p), known mod Fil^M, and no moments. Similarly, an element of (p^rD) / Fil^M could be stored as (p^r, M, (a_0 mod p^(Mc_p - r), ..., a_i mod p^((M-i) * cp - r), ..., a{M-1-r} mod p^((r+1) \ c_p - r)) (where I've dropped the ceiling from the notation for legibility).
— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/43#issuecomment-15645605 .
Another related point -- should the current distributions have an option of being normalized in our modified filtration (i.e. the one that moves nicely in families). This would be great to (a) have a base case to try out this filtration without having to worry about the variable "w" and (b) have a nice space to specialize our families to.
I'm not talking about a whole new data type -- just a field that indicates which way to normalize, and this field is set appropriately when the distribution is created.
On Fri, Mar 29, 2013 at 1:26 PM, Robert Pollack rpollack@math.bu.eduwrote:
Ah! I ran into a similar problem when typing up the details of section 8.1 of our paper. The problem here is that our current filtration comes in p-1 different patterns. Namely, the required valuation typically drops by 1 as we increase the moment except for our exceptional slot (between 0 and p-2) where it stays flat. And this exceptional slot allows for p-1 different patterns.
But, I think, there is no need to do this! Why not just fix a pattern? Let's require the 0-th moment to have valuation at least N c_p and the first moment to again have valuation at least N c_p, and then start dropping for the next p-3 moments, and then repeat... This should still give a nice filtration.
Moreover, the filtration has the following nice uniform description that I was struggling with in section 8.1. Define K_0 to be the distributions whose j-th moment have valuation at least -j c_p. We then have:
p^(ceil(M c_p)) K_0 \cap D
is exactly the filtration I described above. (This description is important in dealing with distributions with infinitely many denominators.)
Would this resolve the accuracy issue you were worried about? If so, let's go with it because I like this uniform filtration better.
On Fri, Mar 29, 2013 at 11:24 AM, rharron notifications@github.comwrote:
I forgot to mention the simple solution: each element has, in addition to an ordp, an M. I've brought up this possibility a couple times for non-families, but then once I understood the "magic" that was going on, I saw that it was unnecessary because you can safely conflate the p-adic precision with the filtration precision. But for families you can't.
If we do this, we could store the zero distribution in D / Fil^M as (p^(M_c_p), M, ()), i.e. valuation p^(M_c_p), known mod Fil^M, and no moments. Similarly, an element of (p^rD) / Fil^M could be stored as (p^r, M, (a_0 mod p^(Mc_p - r), ..., a_i mod p^((M-i) * cp - r), ..., a{M-1-r} mod p^((r+1) \ c_p - r)) (where I've dropped the ceiling from the notation for legibility).
— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/43#issuecomment-15645605 .
(1) Yeah, I think that should work. I had some vague idea in mind that was like that and I'm happy that this question came up for you on the theoretical side at the same time! So, basically, we would take the filtration where the precisions are ceil(N * c_p) - floor(j * c_p). (Note that the current filtration is uniform, but it's uniform from the least significant moment, so really we'd just be switching the orientation in some sense). I'll start changing the families code!
(2) I think it would be better to make a new class, maybe. All that would be involved really is redefining the normalize and _valuation functions I think.
No wait. This is still a problem. Take p = 5 again. The precisions with 8 moments are 6,6,5,4,3,3,2,1, but the precisions with 7 moments are the same, just truncated: 6,6,5,4,3,3,2. In some sense, for it to work it would have to be something where the Mth element of the filtration doesn't have M moments stored: i.e. use a filtration where the precisions on Fil^M start with M, M, M-1, M-2, ... with the doubling every (p-1) and go all the way down to 1. Does that make things nice on the theory side?
Great. Yes. The filtration I'm seeing definitely goes all the way down to 1.
On Fri, Mar 29, 2013 at 5:28 PM, rharron notifications@github.com wrote:
No wait. This is still a problem. Take p = 5 again. The precisions with 8 moments are 6,6,5,4,3,3,2,1, but the precisions with 7 moments are the same, just truncated: 6,6,5,4,3,3,2. In some sense, for it to work it would have to be something where the Mth element of the filtration doesn't have M moments stored: i.e. use a filtration where the precisions on Fil^M start with M, M, M-1, M-2, ... with the doubling every (p-1) and go all the way down to 1. Does that make things nice on the theory side?
— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/43#issuecomment-15661527 .
Cool. This may take some time.
Okay done. The only thing I didn't change was the precision of the output of solve_diff_eqn. Where does mu naturally lie now?
Ugh. I think there is a problem with this new filtration. On the theory side I'm actually seeing that the valuations should go down to 1, but the 1 should be repeated if that's the appropriate next step.
For instance, p=5 would go: 6,6,5,4,3,3,2,1,1 while 5,5,4,3,2,2,1.
Actually, I just did some computations and in fact what we have now isn't a valid filtration.
No no. I messed those numbers up. Try again. For p=5:
7,7,6,5,4,4,3,2,1,1 while 6,6,5,4,3,3,2,1
Do you mean what we have right now isn't a valid filtration, but will become valid if we make it 1,1 when it should be?
Exactly.
This is easy to change yes? Just change the filtration list and the functions length_of_moments and length_reverse-lookup?
Yeah, give me a sec.
Okay done.
Looks resolved. Closing.
The way we do relative precision for overconvergent distributions relies on the basic isomorphism (p^r D) / Fil^M \cong p^r (D / Fil^{M-r}), i.e. if mu is an element of D / Fil^M that happens to be divisible by p, then we can "factor out" the p and drop a moment and consider mu to be an element of D / Fil^{M-1}, but shifted up. Conversely, if we have an element in p (D / Fil^{M-1}), we can also simply think of it as an element of (pD) / Fil^M since the new moment will just be O(p). This is used throughout our code, in particular we want to be able to do this in solving the difference equation (which introduces denominators).
But this doesn't work in families. Take, for instance, p = 5 and M = 4. If mu is in D / Fil^4, then its moments are known to precision 3,3,2,1, respectively, but if nu is in D / Fil^3, its precisions are 3,2,1. So, if mu has moments (p a0, p a1, p a2, p a3), its first moment is known up to p^3. Factoring out p and dropping the last moment yields moments (a0, a1, a2) where a0 is known up to p^2! Crap! The total measure of an element of D / Fil^3 must be known up to p^3. In particular, this means we can't store the 0 distribution in the same way. In our non-families code, we use that we can keep factoring out p and dropping a moment to store 0 as a distribution with no moments. So, the zero distribution in D / Fil^4 (for non-families) is the same as a distribution in p (D / Fil^3), or p^2 (D / Fil^2), p^3 (D / Fil^1), p^4 (D / D), and so is stored as p^4 * (). But for families, if mu = 0 mod Fil^4, then it is not known to be p times something that is zero mod Fil^3. Simply put: p * Fil^3 is not Fil^4.
I'll read carefully what Rob (P) has written in sections 8 and 9 of our paper and see if I can make sense of a good way of dealing with this. But if anyone else has comments, go right ahead!