Hey Jeroen, My understanding of why we coerce to the lower precision is to have at least the required amount of significant figures, and I'd guess doing things this way is more numberically stable. In the same vein, I think we're better off just letting the coercion to go through normally rather than circumventing the element construction for binary operations. At least, I don't see a good use case.
Best, Travis On Tuesday, October 7, 2014 7:03:54 AM UTC-7, 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.
