[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Alex Shinn <alexshinn@xxxxxxxxx>*Subject*: Re: inexactness vs. exactness*From*: bear <bear@xxxxxxxxx>*Date*: Sun, 24 Jul 2005 09:44:25 -0700 (PDT)*Cc*: William D Clinger <will@xxxxxxxxxxx>, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <5fb7e0870507240705438a6915@xxxxxxxxxxxxxx>*References*: <y9loe8sbnhh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <5fb7e0870507240705438a6915@xxxxxxxxxxxxxx>

On Sun, 24 Jul 2005, Alex Shinn wrote: >If you take the idea that inexacts represent single real values, >then all equations have to be qualified with "so long as the values >and intermediate results remain within the precision the system >provides." Yes. That's exactly what the "inexact" status described in the standard means, and exactly how it's used. > If instead you assume that inexacts represent ranges, then the > qualification instead becomes "all values within the range are > indistinguishable." In the above contradiction, x and y when > represented on the computer are indistinguishable from 1.0, > so without any steps at all you can conclude x = y = 1.0. > This goes for any real number, not just 1.0. But that's exactly what the above contradiction means. x = y = 1.0; therefore there is no range here, period. > It is important to distinguish between the mathematical numbers, > the Scheme numbers that attempt to model them, the machine > representations used to implement the Scheme numbers, and > notations used to write numbers. > > Perhaps it is best to leave it this way and let individual people > (and implementations) apply interpretations to those numbers > as suits them. Perhaps. But there is a fundamental point to be made here; the combination of base-10 external notation and base-2 internal representation makes for some strange numeric properties. assuming for a moment that =, >, and < compare strictly numeric values, and also assuming that S and L denote base 2 representations of different length, we get: (= 1.1L1 1.1S1) => #f (< 1.1L1 1.1S1) => #f (> 1.1L1 1.1S1) => #t ;; 1.1 isn't representable in base 2, so extending it ;; to long representation gives a different number on systems ;; where the underlying representation is base 2. (= 1.25L1 1.25S1) => #t (< 1.25L1 1.25S1) => #f (> 1.25L1 1.25S1) => #f ;; But 1.25 is, so using long or short representation, these ;; are literally the same numeric value. On the other hand, if the system uses BCD or rationals or some equivalent to store both L and S formats, you get consistency. (= 1.25L1 1.25S1) => #t (= 1.1L1 1.1S1) => #t (< 1.25L1 1.25S1) => #f (< 1.1L1 1.1S1) => #f (> 1.25L1 1.25S1) => #f (> 1.1L1 1.1S1) => #f So the behavior of the comparison predicates depends on the internal representation and how well it matches the external representation and what kind of rounding was done to represent the answer to a calculation. I think the idea of "neighborhoods" was mainly an excuse to give these operations semantics that somebody thought were desirable in comparing numbers of different internal representation. But I think that covering up numeric differences that are artifacts of the representation system is not actually desirable. The problems are that it will also cover up numeric differences which are not artifacts of the representation system, and that it will cover up differences which will lead to different results in subsequent calculations. The current standard states that comparison operations are not reliable on inexact numbers. This is demonstrably true. Until someone has a truly brilliant idea about how to deal with inexact control flow, I think we should probably leave it at that, because there is a precipice here; the need to return a sensible value from a comparison predicate on inexact numbers creates a compelling case for inexact booleans. But the semantics of control structures like if and cond when dealing with inexact booleans are at best murky, until that truly brilliant idea comes along. Bear

**References**:**Re: inexactness vs. exactness***From:*William D Clinger

**Re: inexactness vs. exactness***From:*Alex Shinn

- Prev by Date:
**Re: inexactness vs. exactness** - Next by Date:
**Re: inexactness vs. exactness** - Previous by thread:
**Re: inexactness vs. exactness** - Next by thread:
**Re: inexactness vs. exactness** - Index(es):