Hello, > The implementation of RR and CC in Sage are a very direct wrapping of > > MPFR, which is the most well-thought out efficient implementation of > > floating point real numbers I've ever seen. It is worth visiting > > http://www.mpfr.org/mpfr-current/mpfr.html and searching for > > "infinity". > > thank you for the pointer. However for questions whether Inf should be in > RR > or not, the MPFR documentation does not say much. About this topic, I > recommend to look at the discussions around the P1788 standard for > interval > arithmetic : <http://grouper.ieee.org/groups/1788/>. > I did not have time to look at any of this material yet, but I think it is good to point out that there are different questions here. I think it is not very controversial that a system for floating-point arithmetic includes +/- infinity and NaN as special values. However, one can argue to what extent these should be regarded as valid numbers, e.g. which operations on "finite real numbers" should be extended to these special values. Of course, it is true that numerical analysts and programmers have thought deeply about this; however, Sage users coming from other fields of mathematics will not expect this behaviour (which is why I was baffled by "Infinity in RR"). In other words, the fact that RR is a fairly thin wrapper around MPFR has good and bad sides.
As for NaN, this can hardly be viewed as anything else than a kind of error code. It is still treated as an element of RR, though: sage: NaN in RR True sage: parent(NaN) Symbolic Ring sage: n = RR(NaN) sage: n NaN For +/- infinity, it at least looks reasonable to treat these as "pseudo-numbers" on which most operations still make sense. This is what Sage's RR does; it is actually closer to the extended real line (the union of {-infinity}, the reals and {+infinity} with the expected topology) than to the reals alone. At the same time +/- infinity do also play the role of error codes, namely for overflow and underflow: sage: 2.^(2.^(2.^10)) +infinity If one views RR as a model of the extended real line, then one could say that this +infinity is not really an error code, but just another instance of rounding. I think a case could be made for having two versions of the current RR: one like the current one (more like a model of the extended real line) and one where overflow or division by zero raises an exception instead of returning +/- infinity (more like a model of the usual real numbers). I can think of at least two reasons for having the latter: (1) it has a better field-like behaviour; this will always be imperfect due to rounding errors, but not having infinity avoids many violations of the field axioms; (2) it interacts better with the complex numbers; R embeds into C and this extends to an identification of R + R*i with C, but the current implementation acts as if this is true with R replaced by the extended real line. This leads to the undesirable fact that Sage's CC now contains many different infinities (namely, all a + b*i where at least one of a, b is infinite; note that this is completely different from e.g. having all r*exp(i*t) with r = Infinity and t in [0, 2*pi), as well as from the fact that in the usual compactification of C (the Riemann sphere) there is only one point at infinity). The question that Greg originally posed (why imag(CC(infinity)) = 0 instead of undefined) stems from this. Peter -- 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/groups/opt_out.