I'd like to expand on these points. Right now, to determine whether a
number is a Real number (as described in mathematics) you need to use a
predicate (and finite? real?). If we kept real? as being what it is
defined in math, then there would be no need for the finite? predicate.
Maybe what we need is a new predicate IEEE754-number? which would be (or
real? infinite? nan?). Based on our previous discussions, this would
probably seem the least controversial view. The only point I'd disagree
with you is what (real? nan.0) should produce. Not being a boolean would
make it very cumbersome to use. I think #f is the most sensible, since
the user can check for nan? and can deal with it as either being
undefined and definitely not real or maybe real.
Right now, it looks like the number system is leaky in the sense that it
forces the user to translate from mathematical definitions and how it's
implemented. Plugging this leak will keep the language sound and allow
implementations the freedom to use the best techniques for math, whether
they are IEEE-754 or another one in the future.
Arthur
Thomas Lord wrote:
> */2.1 Infinities, NaNs/*
> /However, as most Scheme implementation use an IEEE 754-conformant
> implementation [16
> <http://www.r6rs.org/document/rationale-html-5.95/r6rs-rationale-Z-H-28.html#node_bib_16>]
> of flonums, R^6 RS uses the particular semantics from this standard
> as the basis for the treatment of infinities and NaNs in the report.
> This is also the reason why infinities and NaNs are flonums and thus
> inexact real number objects, allowing Scheme systems to exploit the
> closure properties arising from their being part of the standard
> IEEE-754 floating-point representation./
>
>
>
> With that design, the procedure real? is assigned two, mutually
> contradictory roles. On the one hand, it represents a domain over
> which certain Scheme math operators are closed. On the other hand, it
> represents the mathematical concept of membership in the set *R*.
>
> Normal flonums ambiguously denote members of *R*. NaN denotes bottom,
> not a number at all. Plus and minus infinity ambiguously denote
> members of *R* /or/ bottom. An actual (effective, named) bottom (NaN)
> or possible bottom (+/-inf) can arise in a computation either because
> the primitive facilities for flonum math can't represent a result in a
> better way /or because the primitive facilities can prove that no real
> number result is guaranteed to exist/.
>
> That is why the two roles being assigned to the predicate real? are
> mutually contradictory. For the closure properties referred to in the
> rationale, NaN and the inf values must be included. Yet,
> mathematically, NaN is not a number and +/-inf might not be numbers.
>
> Scheme's numeric type predicates have traditionally referred to fairly
> basic mathematical concepts. They distinguish between exact and
> inexact, and between *N*, *R*, and *C* for example, not between
> *Fixnum*, *Bignum*, *Flonum*, etc.
>
> In keeping with that tradition, applying real? to NaN ought not return
> #t for there is nothing about NaN that tells us that a computation has
> yielded some (possibly ambiguous) member of *R*.
>
> For each of the Scheme domains *Real*, *Complex*, etc. (as given by the
> predicates of the same name) we could define a second domain, *Real**,
> *Complex**, etc. which includes both effective bottoms (like NaN) and
> ambiguous values that might denote a bottom (like +/- inf). In that
> way, programs that want to propagate Nan and +/-inf through equations
> and skip the costs of explicit tests for them can use predicates like
> real*? and complex*? while programs that are interested in the
> mathematically certain properties of a value can stick to real? and
> complex?.
>
> The main job for the Scheme standard is to require that procedures which
> are strict in their arguments preserve bottom. That is: if an
> effective bottom is an argument, then the result is bottom; if a
> possible bottom is an argument, then the result must be a possible
> bottom or a bottom. The only exceptions to this rule are type
> predicates that test for effective bottoms or possible bottoms (e.g.,
> nan? or real*?).
>
> An interesting design choice still remains: what should be the value of
> (real? nan.0) or of (real? inf.0)?
>
> The general rule that NaN is a bottom value tells us that, given NaN,
> real? must not return #t but #f seems an equally incorrect answer. NaN
> can arise a computation either because no mathematically correct result
> exists, or because the implementation could not produce a mathematically
> correct result. Programs should not assume that what is denoted by
> NaN either is or is not a member of *R*. Perhaps it is simply an error
> if a program is strict in the question of whether NaN is or is not a
> member of *R*.
>
> -t
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Received on Tue Jun 26 2007 - 13:42:31 UTC