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.
