IMHO way too complicated, and too few people understand coercion as it is already. I'd rather have one unnecessary rounding than ring operations where I can't predict the outcome without reading the source first.
The only takeaway is: If you care about the last decimal places then start by defining your parent RealField with the precision you want. Coercion must always be from higher precision to lower precision, this is the only structure-preserving map. p-adics are even more weird, they coerce in the wrong direction. And, to patch up that mistake, have a precision in the parent and another precision in the element: sage: R = Zp(5, 10) sage: r = R(1) sage: r 1 + O(5^10) sage: Q = Zp(5, 8) sage: q = Q(1) sage: q 1 + O(5^8) sage: r + q # should coerce to Q, and actually makes it look like it 2 + O(5^8) sage: _.parent() # surprise 5-adic Ring with capped relative precision 10 I think this is all driven by Sage's use of ==, which means: after coercion. Which is surely what you expect in interactive use, but devastating once you use it for caching decisions: sage: @cached_function ....: def ulp(x): ....: return x.ulp() sage: ulp(1.0) 2.22044604925031e-16 sage: ulp(RealField(200)(1)) 2.22044604925031e-16 sage: RealField(200)(1).ulp() 1.2446030555722283414288128107560248481180504337442334266202e-60 On Tuesday, October 7, 2014 3:03:54 PM UTC+1, Jeroen Demeyer wrote: > > Hello, > > Consider the following Sage session: > > sage: a = RR(-1) > sage: b = 1.000000000000000000000001 > sage: a + b > 0.000000000000000 > sage: a._add_(b) > 1.03397576569128e-24 > > Here, the coercion model makes the output less precise than what is > possible: a + b first reduces the precision of b, rounding the value to > 1. This is not needed, since the _add_() of RealNumbers actually works > for RealNumbers of different precision. > > I don't know how relevant this issue occurs in practice, my concern is > just theoretical and was motivated by thinking about #15260 and #2034. > > To improve this situation, one could introduce the notion of > "compatible" parents: parent(x) is compatible with parent(y) if there > exists a coercion from parent(y) to parent(x) and x._add_(y) may be > called without changing parents. > > To implement this, we should add a method is_compatible(self, other) on > Parents (which a default of "return False") and then changing > have_same_parent() to have_compatible_parent(), calling this > is_compatible() method if parents are not equal. Alternatively, this > could probably be implemented using actions. The rules about choosing a > common Parent for the result do not change. > > One possibly annoying consequence would be that _rsub_ and _rdiv_ > methods will be needed on Elements of Parents implementing > is_compatible(). This is because a._sub_(b) would return an object with > a different Parent as b._rsub_(a). > > At first sight, the only Parents which would benefit from this are > floating-point Parents with different precisions. > > Any objections about this proposal? > > Jeroen. > -- 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.
