search

lalitkumarj / OMSCategory

Sage Category implementation of OMS
1 stars 1 forks source link

accuracy in difference equation #40

Closed rpollack9974 closed 11 years ago

rpollack9974 commented 11 years ago

When solving the difference equation with nu in D/Fil^M the result mu such that mu | Delta = nu naturally lives in p^(-m) D/Fil^(M-1) where m = floor(log_p(M)). Thus mu should have absolute precision p^(M-1-m) -- our programs need to be modified to reflect this.

rharron commented 11 years ago

I'm working on this.

rharron commented 11 years ago

So, you mean if nu has absolute precision M, then mu should have absolute precision M-1-m, i.e. if nu is in p^r(D/Fil^M), then mu naturally lives in p^(r-m)(D/Fil^(M-1)). I'm not sure I'll get this done before having to make dinner.

rpollack9974 commented 11 years ago

Exactly -- as long as by p^r(D/Fil^M) you mean p^rD/p^rFil^M.

On Thu, Mar 28, 2013 at 7:20 PM, rharron notifications@github.com wrote:

So, you mean if nu has absolute precision M, then mu should have absolute precision M-1-m, i.e. if nu is in p^r(D/Fil^M), then mu naturally lives in p^(r-m)(D/Fil^(M-1)). I'm not sure I'll get this done before having to make dinner.

— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/40#issuecomment-15621259 .

rharron commented 11 years ago

What about in families with the new filtration?

rpollack9974 commented 11 years ago

OK -- so it basically should work the same way -- namely, we need to drop the last moment and the absolute precision should drop by an additional m. However, in this new filtration you can't just drop 1 moment -- for instance, when p=5 the possible number of moments are 2,3,4,5,7,8,9,11,... and so you if have 7 moments you will actually need to drop 2 moments.

rpollack9974 commented 11 years ago

Sorry -- no need to describe this in terms of dropping moments. If you start out modulo the M-th filtration, then the answer naturally lives in p^(-m) D / p^(-m) Fil^(M-1) -- just like in the fixed weight case.

rharron commented 11 years ago

I think we'll need to rewrite the solve_diff_eqn for families that avoids delegating to the non-families function because of how much extra precision we now have in families.

rpollack9974 commented 11 years ago

I'm confused. What extra precision?

On Thursday, April 4, 2013, rharron wrote:

I think we'll need to rewrite the solve_diff_eqn for families that avoids delegating to the non-families function because of how much extra precision we now have in families.

— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/40#issuecomment-15907217 .

rharron commented 11 years ago

Well, if I have a family mus with precision M, then the moments have precision M, M, M-1, M-2, ... 2, 1, which is a tuple of length M + ceil((M - 1) / (p - 2)). Right now, we would... oh wait, I guess when we delegate to the non-families we just have to do so with sufficient precision. Here's how I think about these things: the precision in non-families is a line (well a "constant slope" step function) from (0, M) to (M-1, 1), whereas the precision in families is a more slowly decreasing function winding its way from (0, M) to (M - 1 + ceil((M-1) / (p-2)), 1. So, if you have a non-family of precision M, you can't just lift it to precision M, you need to find the largest M' <= M such that a precision M in families has length at most M'. (This M' is returned by the method .length_reverse_lookup(M) of the parent class) So, if mus has precision M, we need to create the mu with least precision N >= M whose N' is >= M. Or no such that (N - 1 - n)' >= M - 1 - m?

rpollack9974 commented 11 years ago

right. I used that reverse_lookup function several times to fix up solve_diff_eqn.

ideally, we would have a class of distributions of a fixed weight with the modified filtration. then the families could just refer to this class.

On Thu, Apr 4, 2013 at 12:37 PM, rharron notifications@github.com wrote:

Well, if I have a family mus with precision M, then the moments have precision M, M, M-1, M-2, ... 2, 1, which is a tuple of length M + ceil((M

  • 1) / (p - 2)). Right now, we would... oh wait, I guess when we delegate to the non-families we just have to do so with sufficient precision. Here's how I think about these things: the precision in non-families is a line (well a "constant slope" step function) from (0, M) to (M-1, 1), whereas the precision in families is a more slowly decreasing function winding its way from (0, M) to (M - 1 + ceil((M-1) / (p-2)), 1. So, if you have a non-family of precision M, you can't just lift it to precision M, you need to find the largest M' <= M such that a precision M in families has length at most M'. (This M' is returned by the method .length_reverse_lookup(M) of the parent class) So, if mus has precision M, we need to create the mu with least precision N >= M whose N' is >= M.

— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/40#issuecomment-15908560 .

rharron commented 11 years ago

So, are you fixing up solve_diff_eqn? (and random_element?)

rpollack9974 commented 11 years ago

I pushed code this morning -- but my fixes aren't nice. They are just hacked together to get things working.

Now that solve_diff_eqn isn't crashing, I'll try to get random not to crash...

On Thu, Apr 4, 2013 at 12:54 PM, rharron notifications@github.com wrote:

So, are you fixing up solve_diff_eqn? (and random_element?)

— Reply to this email directly or view it on GitHubhttps://github.com/lalitkumarj/OMSCategory/issues/40#issuecomment-15909610 .

rharron commented 11 years ago

This has been addressed. Closing.