Thanks for all the replies. It seems that everybody here agrees to disallow coercions from RR to RIF, which is all that ticket http://trac.sagemath.org/ticket/15114 is about, so that ticket can proceed.
As for conversions or coercions RIF to RR, there doesn't seem to be anybody strongly in favour having them, and it is not clear how it should work, so I won't touch them. 2014-03-19 16:39 GMT+01:00 Robert Bradshaw <rober...@math.washington.edu>: > +1 to all of this, specifically > > 1) allow > 2) allow for point intervals (maybe) > 3) dissallow > > On Tue, Mar 18, 2014 at 3:02 PM, David Roe <roed.m...@gmail.com> wrote: >> Marc Mezzarobba wrote: >>>Marco Streng wrote: >>>> So the choices are: >>>> >>>> 1) explicit conversion RR --> RIF: allow / disallow >>>> 2) explicit conversion RIF --> RR: allow / disallow >>>> 3) automatic coercisions: disallow / (RR-->RIF) / (RIF-->RR) >>>[...] >> >>>> My vote is: >>>> 1) allow >>>> 2) allow >>>> 3) from RIF to RR >>> >>>Mine is: >>> 1) allow >> >>> 2) allow for point intervals, require the use of explicit method calls >>> (e.g., center()) for general intervals >>> 3) disallow (but see below) >>> >>> Regarding 3), and in response to Thomas Coffee's arguments, I would be >> >>> in favor of also having "non-rigorous intervals", living in a separate >>> parent, with a coercion from RR. In fact, one also needs intervals with >>> integer, rational or even symbolic endpoints from time to time. So >>> unless I'm missing something, these "non-rigorous interval" could simply >>> be the elements of Intervals(RR), where Intervals(C) would work for more >>> or less arbitrary C. (And there could perhaps be a coercion from RIF to >>> Intervals(RR), but certainly not in the other direction.) >> >> I agree with Marc, though I note that C needs at least a partial ordering, >> which most rings don't come with. >> >> On Tue, Mar 18, 2014 at 2:16 PM, Thierry <sage-googlesu...@lma.metelu.net> >> wrote: >>> >>> >>> It seems there are more precise cases to consider: >>> >>> - How do you plan to coerce a RIF element with non-trivial diameter to a >>> RR element ? >> >> >> I would say you don't even allow conversion in this case, let alone >> coercion. >> >>> >>> - How do you plan to convert >>> - from RealIntervalField(2) to RealField(100) ? >> >> If you start with a point interval, there's no problem. Otherwise, >> disallowed. >>> >>> - from RealIntervalField(100) to RealField(2) ? >> >> Conversion should work as long as the upper and lower endpoints are the same >> in RealField(2). >>> >>> - from RealField(100) to RealIntervalField(2) ? >> >> Smallest interval containing the input. >>> >>> - from RealField(2) to RealIntervalField(100) ? >> >> Here you can use a point interval as the image. >> >> Of course, none of these should be coercions. >> >>> >>> - How do you mix both (do you plan to deal with possible compensations >>> between number of bits of precision of the field and the diameter of >>> the intervals) ? >> >> >> I would say yes: you can mix a change in precision with a change in >> precision type. >> >>> >>> For example, in which case do you allow (silent) coercion, and what >>> should be the result of the (explicit) conversion: >>> >>> - RIF(-1,1) -> RR >> >> Coercion and conversion should both fail. >>> >>> - RealIntervalField(100)(1.000000001,1.000000002)) -> RealField(2) >> >> Coercion and conversion should both fail. >>> >>> - RealField(2)(pi) -> RIF [which diameter, which endpoints ?] >> >> A point interval (3.0, 3.0) >>> >>> >>> >>> As for me, >>> - it is clear that RIF(pi) should be coerced to RR(pi) >> >> I think that this actually isn't clear, since RIF(pi) is not a point >> interval. Of course, we could make a special case when the length of the >> interval is the minimum possible, and use the rounding mode of RR to >> determine which endpoint to pick (though I don't know what we should do in >> the default 'RNDN' >>> >>> - i agree with coercing from x in RealIntervalField(a) to RealField(b) >>> when the endpoints of x are the same in RealField(b) >> >> Coercion needs to be defined on the whole domain. This rule works for >> conversion though. >>> >>> - i have no problem for explicit conversion from RIF(-1,1) to RR, but it >>> should be well specified in the doc, since there is no canonical way. >> >> I think it should be disallowed, since there are already functions to get >> the lower, upper and center. >>> >>> - i am not sure wether RIF(-1,1) should coerce to RR >> >> Definitely not. >> >>> >>> Is Sage able to allow a coercion from A to B, but the coercion map is >>> not the same as the conversion map there (i mean, could the coercion be >>> a partial map of the conversion) ? >> >> No. If a coercion exists, it must be defined on all of A and must agree >> with the conversion map from A to B. >>> >>> >>> As for me, i am against RR -> RIF coercion because some Sage code (not >>> user code) could convert from RIF to RR because of some internal >>> multiplication, and then silently back to RIF (if the coercion RR->RIF >>> were allowed), leading to a false sense of precision and even the >>> experienced user will not noticing it (no none can be assumed to know >>> all Sage source code), and will not be able to hand-check this as >>> suggested in the comment, since not all computations are done by the >>> user. >> >> >> +1 >> >>> >>> BUT, i find the second example of tcoffee quite convincing (i am also >>> doing some RIF stuff to understand the loss of precision along a >>> computation), so perhaps could there be an easy way to let the user tune >>> such a convenient coercion easily at her own risks, and a way to learn >>> about this. Or perhaps could there be a special parent for this kind of >>> experiments. >> >> >> I think Marc's suggestion of a different parent is the best one, though of >> course requires more work. >> David >>> >>> >>> Ciao, >>> Thierry >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sage-devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to sage-devel+unsubscr...@googlegroups.com. >>> To post to this group, send email to sage-devel@googlegroups.com. >>> Visit this group at http://groups.google.com/group/sage-devel. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-devel@googlegroups.com. >> Visit this group at http://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
