2012-08-27 07:15:45

WG1 - Core

Draft 6 says that it's an error for an argument of `/` (other than the first) to be an exact zero. R6RS, however, says that it's an error only if ''all'' the arguments are exact. In other words, `(/ 2.0 0)` is an error according to the draft, but in R6RS it returns `+inf.0` (assuming the implementation supports it). The proposal is to adopt the R6RS wording. I tested `(/ 2.0 0)` in the usual set of Schemes: * Racket, Gambit, Chicken (with the numbers egg), Guile, Chibi, Elk, Spark report an error. * Gauche, Bigloo, Scheme48/scsh, Kawa, SISC, Chez, SCM, !Ikarus/Vicare, Larceny, Ypsilon, Mosh, !IronScheme, NexJ, STklos, RScheme, BDC, UMB, VX return `+inf.0`. * MIT, scsh, Shoe, !TinyScheme, Scheme 7, XLisp, Rep, Schemik, Inlab always report an error when dividing by zero, exact or inexact. * KSi, Scheme 9 produce incorrect results. * !SigScheme, Dream, Oaklisp, Owl Lisp don't support inexact numbers.

367

alexshinn

major

cowan

wontfix

closed

Inexact division by exact zero

2012-03-28 00:38:17

defect

cowan

comment

3

1346026545394434

367

2012-08-27 07:15:45

cowan

resolution

wontfix

1346026545394434

367

2012-08-27 07:15:45

cowan

status

closed

decided

1346026545394434

367

2012-08-27 07:15:45

cowan

comment

WG1 decided to make no change, keeping the R5RS rules.

2

1345829609432653

367

2012-08-25 00:33:29

cowan

status

decided

new

1345829609432653

367

2012-08-25 00:33:29

cowan

comment

Here is a Galilean dialogue between Sixer, a proponent of the R6RS rule, and Fiver, a proponent of the R5RS rule, which is the same as that of R7RS draft 6. Sixer: Why shouldn't `/` should do inexact contagion, just like the other arithmetic operations? Fiver: Because an inexact operation may return an exact result if it can prove that the inexactness can't affect the result, like `(* 1.0 0)` returning `0` rather than `0.0`. Sixer: Certainly. But what has that to do with it? Fiver: Dividing by exact 0 doesn't care about the inexactness of the other arguments. There is no exact infinity in Scheme, so it's more appropriate to report an error representing the non-existent value. Since we don't require errors to be signalled except in a few circumstances, "is an error" is the appropriate phrase. Sixer: The value `+inf.0` can be understood as covering both overflow and positive affine infinity. Surely that's the least surprising result when inexact numbers are involved? Fiver: But why should the result of dividing by an exact 0 be positive rather than negative? Zero, after all, is neither. Sixer: [http://en.wikipedia.org/wiki/Discordianism#Philosophy I don't know, man, I didn't do it], but IEEE 754 says so. Fiver: Well, anyway, "is an error" covers both raising an exception and returning `+inf.0`. Sixer: True, but numerical programmers expect to be able to rely on the IEEE rules, instead of the bad old days when division by zero always crashed your program. Fiver: Then let them avoid exact numbers. Sixer: Maybe. Is that realistic? I don't know. Fiver: Me either.

1

1333042956478863

367

2012-03-30 00:42:36