Opened 5 years ago
Closed 5 years ago
#367 closed defect (wontfix)
Inexact division by exact zero
Reported by: | cowan | Owned by: | alexshinn |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | WG1 - Core | Keywords: | |
Cc: |
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.
Change History (3)
comment:1 Changed 5 years ago by cowan
comment:2 Changed 5 years ago by cowan
- Status changed from new to decided
WG1 decided to make no change, keeping the R5RS rules.
comment:3 Changed 5 years ago by cowan
- Resolution set to wontfix
- Status changed from decided to closed
Note: See
TracTickets for help on using
tickets.
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: 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.