On Thursday, March 10, 2016 at 6:04:49 PM UTC+1, William wrote:
>
> On Thu, Mar 10, 2016 at 7:41 AM, Thierry
> <[email protected] <javascript:>> wrote:
> > On Thu, Mar 10, 2016 at 08:17:43AM +0100, Jeroen Demeyer wrote:
> >> On 2016-03-09 23:56, Thierry wrote:
> >> >Willing to
> >> >change the behaviour will be similar to requesting that 'NaN in RR'
> should
> >> >return False.
> >> Not the topic of this thread, but I really think that "NaN in RR"
> should
> >> return False. RR represents the real numbers and NaN is *not a number*.
> >
> > RR does *not* correspond to the real numbers, at least not in the way
> that
> > NN, ZZ, QQ, AA, QQbar do. RR is just a MPFR representation of numbers,
> > among various other representations, such as RDF, RIF, RBF,... The
> > particular RR name is ill-chosen, but RR is nothing but a slower
> > implementation of RDF, whose second letter clearly insist on the
>
> RR (=RealField(53)) is absolutely not "nothing but a slower
> implementation of RDF". With RR you get arbitrary precision
> exponents, whereas with RDF you do not. This is an important
> distinction for some computations, which I've personally run into in
> practice (e.g., when implementing Sage's determinant algorithm for
> integer matrices):
>
> sage: RDF(1e99999)
> +infinity
> sage: RR(1e99999)
> 1.00000000000000e99999
>
Minor correction: RR exponents are not *arbitrary* precision, though much
higher precision than RDF. This still happens:
sage: RR("1e99999999999999999999")
+infinity
RBF, mpmath, and (if I remember correctly) also Python's Decimal do have
arbitrary precision exponents. You can do this:
sage: RBF(10) ^ 99999999999999999999
[1.000000000000000e+99999999999999999999 +/- 4.88e+99999999999999999981]
However, RBF(1e99999999999999999999) and RBF("1e99999999999999999999")
don't currently work as intended, which is a bug in Sage (the C function
arb_set_str should be able to create correct values from such decimal
literals, but it is not being used by Sage).
>
> > representation (an information that is missing for RR). The benefit of
> > MPFR over CPU-floats is when we use more than 53 bits of precision. The
> > focus on MPFR among other representations is imho a mistake.
> >
> > See http://trac.sagemath.org/ticket/17713#comment:3
>
> I called it "RealField" for consistency with Magma, which has
> precisely the same model. Consistency with Magma is valuable.
>
>
IMHO, it's a mistake to look at any single software for guidance. Magma,
Maple, Mathematica and Matlab all have different models of real numbers,
and Sage's mission is not just to be a viable alternative to Magma. Some
models are better than others for different applications. (It's also a fact
that Magma, Maple, Mathematica and Maple all get real numbers utterly
wrong. To be fair, it's a mathematical theorem that you can't get real
numbers right on a computer. But there are certainly mistakes in those
systems that Sage doesn't need to repeat.)
Matlab lives in a world where IEEE floats/doubles basically are synonymous
with real numbers. This clearly appeals to scientists and engineers.
Matlab's model is a good example of KISS design, and for all its
limitations, it's at least predictable and useful in certain application
domains. I think this is one major reason why many SciPy users aren't Sage
users.
Mathematica lives in a world where anything is synonymous with an untyped
symbolic expression. From Mathematica's point of view, any mathematical
object worth representing can be represented by an exact symbolic
expression, at least in principle. In practice, Mathematica also includes
an idiosyncratic and half-broken form of significance arithmetic for
representing approximate real numbers as part of symbolic expressions.
Anyway, Mathematica more or less tries to dissociate implementation logic
from user-facing mathematical logic, and it knows at least this:
In[1]:= Element[Infinity, Reals]
Out[1]= False
That said, the question of what "x in RR" should mean in Sage is mostly a
matter of syntax, but it's not a completely superficial matter. The fact
that Sage provides multiple implementations of real numbers with different
pros and cons is a good thing. I think the case can be made for having an
abstract RR (perhaps with another name) really representing the real
numbers, and making the conceptual separation between real numbers (as a
mathematical concept) and floating-point/interval/lazy/other approximations
even stronger. My own biased opinion is also that interval arithmetic
should be used and encouraged more in Sage... I would also like lazy real
numbers to be more useful than they are currently, and overall it would be
nice to have numerical functionality much better integrated with symbolic
expressions (which is something that Mathematica does *extremely* well).
Fredrik
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
