the ticket https://trac.sagemath.org/ticket/15114 seems orphan now...
Am Donnerstag, 20. März 2014 12:58:30 UTC+1 schrieb Marco Streng: > > 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 <[email protected] > <javascript:>>: > > +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 <[email protected] > <javascript:>> 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 <[email protected] > <javascript:>> > >> 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 [email protected] <javascript:>. > >>> To post to this group, send email to [email protected] > <javascript:>. > >>> 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 [email protected] <javascript:>. > >> To post to this group, send email to [email protected] > <javascript:>. > >> 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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
