I think Robert's said it fairly well. Which is good, since I'll have spotty internet for the next couple weeks, and my battery is about to run out.
On 5/15/10, Robert Bradshaw <rober...@math.washington.edu> wrote: > On May 14, 2010, at 11:13 AM, Simon King wrote: > >> Hi Robert! >> >> On 14 Mai, 18:34, Robert Bradshaw <rober...@math.washington.edu> >> wrote: >>>> 1. Do you agree this is a bug? >>> >>> The p-adic fields are of capped precision, not set precision, but >>> each >>> element remembers its own actual precision, so this is why the >>> coercion goes in that direction, and I don't think its a bug. >> >> What does capped or set precision mean? >> >> Is it like this? >> - The precision of the elements of RR is determined by RR, and so the >> precision must be non-increasing along a coercion. > > Yep, otherwise elements have spuriously high precision. > >> - The precision of the elements of one p-adic ring can be different, >> but there is an upper bound for the precision. This upper bound must >> be non-decreasing under coercion. > > Yep, otherwise we loose information. > >>> If we're going to change this, it should be on its own ticket as it's >>> quite a big change. >> >> I thought it is just changing one byte: '>' to '<'. > > :). There are many places I could just change '>' to '<' that would > wreck havoc all over, the above would be a big semantic change. > >> Anyway, if you say we should keep it then I need to do a change in a >> different place: The Completion construction functor allows merging, >> and the rule is that two Completion functors with respect to the same >> prime (resp. +Infinity, for the completion functor yielding RR) are >> merged so that the *smaller* precision results. >> >> By consequence, if you have two parent structures based on p-adic >> rings of different precision, then it could be that there is no >> coercion into their pushout. >> >> Solution: In the merge method, I can distinguish the case "completion >> at +Infinity" and "completion at some prime", so that the smaller >> precision is chosen in the first case and the bigger precision in the >> second case. > > Yes, we'd have to special case this. > > > On May 14, 2010, at 11:39 AM, Simon King wrote: > >> Would the following be what you want? >> >> sage: R1.<a> = Zp(5,prec=20)[] >> sage: R2 = Qp(5,prec=40) >> sage: R2(1)+a >> (1 + O(5^20))*a + (1 + O(5^40)) >> >> This results when one changes the merge method (and makes fraction >> field functor and completion functor commute). > > Yep, that looks right to me. (Sometimes, though, I wonder if the > generator of a inexact ring should be considered to have infinite > precision, but that's totally separate.) > > - Robert > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
