# [R6RS] string->number

dyb at cs.indiana.edu dyb at cs.indiana.edu
Wed Aug 30 13:25:28 EDT 2006

> > True, but it shouldn't preclude a sensible implementation based on IEEE
> > arithmetic.
>
> That's a red herring.  Nobody is advocating anything
> that would preclude a sensible implementation based
> on IEEE arithmetic.  It is the insensible ones that
> are being questioned.

Treating (/ 0 x) as 0 is perfectly sensible if you believe that IEEE +0.0
and -0.0 cannot be exactly 0.  And if you believe that they can both be
exact 0 and hence can both be the same, you'd better explain why the
numeric values of (/ 1 +0.0) and (/ 1 -0.0) are so radically different.

> > > More importantly, implementations are not supposed
> > > to return an exact number for things like (/ 0 0.0)
> > > unless they can prove that the result they want to
> > > return is the correct result for all substitutions
> > > of exact numbers for the inexact ones.
> >
> > Is this new in R6RS?
>
> No.  The behavior of (/ 0 0.0) in Chez Scheme and MzScheme
> is as illegal under the R5RS semantics as under the R6RS.

I disagree wrt R5RS semantics, and I've yet to find anything in the R6RS
semantics that renders this behavior illegal.  Indeed, the committed
version of the R6RS specifically allows allows (/ 0 0.0) to evaluate to 0.

> > If so, I object.  The R5RS requirement was less
> > stringent
>
> No, it wasn't.  R5RS 6.2.2 says:
>
>     With the exception of inexact->exact, the operations
>     described in this section must generally return
>     inexact results when given any inexact arguments. An
>     operation may, however, return an exact result if it
>     can prove that the value of the result is unaffected
>     by the inexactness of its arguments. For example,
>     multiplication of any number by an exact zero may
>     produce an exact zero result, even if the other
>     argument is inexact.

That's what I thought.  But you claimed the proof would have to be made
for "all substitutions of exact numbers for the inexact ones", which means
that I can't reduce (/ 0 3.5) to 0 because if I were to substitute 0 for
3.5 in (/ 0 3.5) I would get (/ 0 0) which (we both agree) is not 0.

Perhaps you meant to imply some sort of equivalence in the substitution.
But all exact equivalents of +0.0 and -0.0 are nonzero, so that would not
preclude (/ 0 +0.0) from evaluating to 0.

> > and, by the way, specifically allowed (* 0 x) to be 0 for any
> > number x including, presumably, NaNs.
>
> That is another red herring.  Everyone agrees that, for
> all exact numbers x, an exact 0 is the correct result of
> (* 0 x).  Therefore everyone agrees that both the R5RS
> and R6RS allow (* 0 x) to evaluate to an exact 0 for any
> number x.

Really?  What about these two examples in base.tex:

(* 0 +inf.0)                           \ev  0 \textit{or} +nan.0
(* 0 +nan.0)                           \ev  0 \textit{or} +nan.0

Kent