This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Source for ticket #367

cc


    

changetime

2012-08-27 07:15:45

component

WG1 - Core

description

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.

id

367

keywords


    

milestone


    

owner

alexshinn

priority

major

reporter

cowan

resolution

wontfix

severity


    

status

closed

summary

Inexact division by exact zero

time

2012-03-28 00:38:17

type

defect

Changes

Change at time 2012-08-27 07:15:45

author

cowan

field

comment

newvalue


    

oldvalue

3

raw-time

1346026545394434

ticket

367

time

2012-08-27 07:15:45

Change at time 2012-08-27 07:15:45

author

cowan

field

resolution

newvalue

wontfix

oldvalue


    

raw-time

1346026545394434

ticket

367

time

2012-08-27 07:15:45

Change at time 2012-08-27 07:15:45

author

cowan

field

status

newvalue

closed

oldvalue

decided

raw-time

1346026545394434

ticket

367

time

2012-08-27 07:15:45

Change at time 2012-08-25 00:33:29

author

cowan

field

comment

newvalue

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

oldvalue

2

raw-time

1345829609432653

ticket

367

time

2012-08-25 00:33:29

Change at time 2012-08-25 00:33:29

author

cowan

field

status

newvalue

decided

oldvalue

new

raw-time

1345829609432653

ticket

367

time

2012-08-25 00:33:29

Change at time 2012-03-30 00:42:36

author

cowan

field

comment

newvalue

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.

oldvalue

1

raw-time

1333042956478863

ticket

367

time

2012-03-30 00:42:36