53 | | 4. In the R6RS, the clause requiring `eqv?` to return `#t` for inexacts explicitly requires that `=` return `#t` as a prerequisite. My formulation does not explicitly require this, but it requires the same prerequisite indirectly (unless both are !NaNs), because if ''z,,1,,'' and ''z,,2,,'' are not `=`, then `(+ z1)` and `(+ z2)` are substantially different. |
| 54 | * Nontrivial change: Restrict use of the predicate "operationally equivalent" to cases where both arguments are inexact. |
55 | | In summary, I would conjecture that the only difference in the resulting requirements (comparing with those ''intended'' by the R6RS and likely implemented in practice) has to do with change #1 above. |
| 56 | * Stylistic change: Move the "same results (in the sense of `eqv?`)" language into the new auxiliary predicate ''substantially different''. |
| 57 | |
| 58 | * Significant change: Eliminate the circularity by changing the definition of "substantially different" for two numbers to use `=` instead of `eqv?`. |
| 59 | |
| 60 | * Significant change: Fix the NaN problem by making sure that two numbers can only be substantially different if at least one of them is numerically equal to itself. |
| 61 | |
| 62 | * Significant change: Restrict the set of procedures that can be used to construct ''f'', and use the R7RS terminology, changing "Scheme's standard arithmetic procedures" to "the standard numerical operations specified in section 6.2.6" |
| 63 | |
| 64 | * Significant change: Properly handle the case where `(f z_1)` or `(f z_2)` raise exception(s). Change "`(f z_1)` and `(f z_2`) yield results that are not substantially different" to "`(f z_1)` and `(f z_2)` either both raise exceptions or yield results that are not substantially different." |
| 65 | |
| 66 | * Significant change: Make sure that the case where both arguments are NaNs is left unspecified by requiring, in the inexact clauses, that at least one argument is numerically equal to itself. |
| 67 | |
| 68 | * Simplification: Remove the redundant check for numerical equality as a prerequisite for `eqv?` returning `#t`. |
| 69 | |
| 70 | Rationale: If ''obj,,1,,'' and ''obj,,2,,'' are not numerically equal (and not both !NaNs), it trivially follows that ''obj,,1,,'' and ''obj,,2,,'' are not operationally equivalent, since `(+ obj_1`) and `(+ obj_2)`are substantially different. |
| 71 | |
| 72 | * Significant change: Relax the requirements for returning `#t` for `eqv?` on inexacts to the cases where "the implementation is able to prove" operational equivalence. |
| 73 | |
| 74 | We now require only that the "implementations must be able to prove that two inexact numbers with the same internal representation are operationally equivalent. |
| 75 | |
| 76 | Rationale: It may be difficult or impossible for the implementation to prove that two inexact numbers are operationally equivalent. |