Thierry wrote: > - How do you plan to convert > - from RealIntervalField(2) to RealField(100) ?
Promote both endpoints. > - from RealIntervalField(100) to RealField(2) ? Round each endpoint in the appropriate direction. > - from RealField(100) to RealIntervalField(2) ? Round the input in both directions. > - from RealField(2) to RealIntervalField(100) ? Promote the input, return a point interval. (I.e.: The precision of a floating point number does not imply anything about its "accuracy", whatever that really means.) > - 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 don't think there is an issue here. > For example, in which case do you allow (silent) coercion, and what > should be the result of the (explicit) conversion: > > - RIF(-1,1) -> RR > - RealIntervalField(100)(1.000000001,1.000000002)) -> RealField(2) No coercion, no conversion. It is not much harder to write iv.lower(), iv.center(), Reals(2)(iv.center())... or whatever you really want. > - RealField(2)(pi) -> RIF [which diameter, which endpoints ?] Point interval. > - it is clear that RIF(pi) should be coerced to RR(pi) I beg to differ. > - i agree with coercing from x in RealIntervalField(a) to RealField(b) > when the endpoints of x are the same in RealField(b) As far as I understand, coercion maps are supposed to be total. > - 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. ...and IMHO in the code too, since there is also no single reasonable choice, and hence not be a conversion. > - i am not sure wether RIF(-1,1) should coerce to RR Definitely not. > 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. Besides the fact that it is cleaner than a "special mode" in which RIF would support coercion from RR, I think a hint that you want a separate parent is that the requirements in this kind of scenarios are not those of interval arithmetic. For example, if I understand correctly, you do not need the (otherwise fundamental!) property that the endpoints are rounded in the right direction after each arithmetic operation. -- Marc -- 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.
