| From: Bradley Lucier <lucier_at_math.purdue.edu>
| Date: Thu, 25 Jan 2007 23:15:09 -0500
|
| ---
| This message is a formal comment which was submitted to
| formal-comment_at_r6rs.org, following the requirements described at:
|
http://www.r6rs.org/process.html
| ---
| Name: Brad Lucier
| email: lucier_at_math.purdue.edu
| Type of issue: Defect
| Priority: Depends on your point of view, I suppose; probably minor, on average
| R6RS component: Arithmetic
| Version of the report: Revised5.92 Report on the Algorithmic Language Scheme
| Summary: floor, ceiling, truncate, and round are unnecessarily over-specified on infinities and NaNs
| Description:
|
| On page 44 of the main body of the report, the description of
| floor, ceiling, truncate, and round contains the text
|
| > Although infinities and NaNs are not integers, these pro-
| > cedures return an infinity when given an infinity as an ar-
| > gument, and a NaN when given a NaN.
|
| The same text appears in the "Standard Libraries" document when
| describing the flonum-specific versions of the same functions,
| namely flfloor, flceiling, fltruncate, and flround.
|
| I consider the fact that the flonum versions of these operations
| are designed to operate in this way to be an optimization issue, in
| that common hardware implementations of IEEE 754 arithmetic act in
| this way, just as both R5.92RS flsqrt *may* return a NaN and IEEE
| 754 sqrt *is defined* to return NaN when given the argument "-1.".
| In R*RS, however, "(sqrt -1)" is expected to do "the right thing"
| and return a complex imaginary unit if complex numbers are
| available.
|
| I have argued in the past, and will continue to do so, that the
| generic arithmetic versions of these functions should return only
| integers, and that, in a "safe" environment (I know, I know, the
| existence of such things are no longer mandated) passing an
| infinity or a NaN to these four functions should throw an
| exception. I believe that implementations should be given the
| freedom to do exactly that. If people want the IEEE 754 behavior
| of these functions, they can call the fl* versions of these
| functions.
I agree.
| So I suggest that the current wording should be kept in the
| specification of the fl* versions of these functions, and be
| removed from the main body of the report.
Similarly, fl<, fl>, fl<=, fl>=, flnegative?, flpositive? should be
required to accept +nan.0 as an argument (as is currently worded),
while the wording for the generic operations <, >, <=, >=, negative?,
positive? should be changed so that they are not required to accept
+nan.0 as an argument.
Received on Fri Feb 02 2007 - 11:51:48 UTC