On 12/18/2012 6:52 AM, Stavros Macrakis wrote:
> Rich, I never said that 3.0 represented an interval -- I said it
> represented /some number/ in the interval, and in general, we don't
> know /what /number. It could be the result of the calculation 3 +
> 1e-100, 3 - 1e-50, etc. Just because it represents something other
> than exact 3 doesn't mean that we shouldn't calculate with it as
> though it were exact 3 in general. Whether you want to treat 3.0 as
> integerp probably depends on the context....
I suppose we agree... 3.0 is a single unambiguous number in the
computer. You may interpret it as something else, like
a crude value for pi. That is your choice. It doesn't make
computational sense to have the computer system
gratuitously assert on your behalf that 3.0 might be something that it
doesn't know about, ...but you are free to
believe that pi is 3.0.
>
> The Scheme notion of exact/inexact seems to capture the right intuitions.
My first reaction is that this is not a solution
(a) The history or derivation of a number seems to affect whether
it is exact or inexact. I'm not sure this works with input and output
of numbers.
(b) The important criterion of equality has not been mentioned. Is
(equal? 3 3.0) true in Scheme
[if equal? is the right name of the predicate] Are programmers going
to have
to worry about transitivity of the equality relation, testing whether
quantities that
are equal are also both exact or possibly inexact?
(c) There is a transition allowed from exact to inexact, perhaps at
overflow or underflow??
that I don't understand. Perhaps (/ 1 0) becomes a floating
Infinity? Or what?
(d) The practical issues of dealing with numbers, like exception
handling, are not
mentioned here. Are they unaddressed in Scheme as they are in CL (and
Maxima)?
RJF
>
> -s
>
> On Tue, Dec 18, 2012 at 6:04 AM, Mark H Weaver <mhw at netris.org
> <mailto:mhw at netris.org>> wrote:
>
> Richard Fateman <fateman at eecs.berkeley.edu
> <mailto:fateman at eecs.berkeley.edu>> writes:
>
> > On 12/17/2012 3:52 PM, Stavros Macrakis wrote:
> >
> > I'd say that floats represent imprecise or
> approximate numbers, so
> > 3.0 might mean exactly 3 or some other number in the interval
> > 3-eps .. 3+eps.
>
> [...]
>
> > I suspect that "professional"
> > numerical analysts would, by and large, say that floats represent
> > exactly some particular number. That is,
> > 3.0 represents exactly the quantity 3.
>
> I certainly agree that 3.0 should not be considered an interval. In
> addition to the points raised by Richard, I'll add that the interval
> 3-eps .. 3+eps does not contain the true result of all computations
> that produce 3.0. In fact, no finite interval can do so.
>
> At the same time, I agree with Stavros' assertion that floats
> should be
> considered "imprecise or approximate numbers". I think it's
> possible to
> adopt this position while simultaneously agreeing with numerical
> analysts that 3.0 represents a single quantity that is equal to 3.
>
> Scheme's number system includes some innovations that are helpful to
> resolve tensions such as this. Notably, Scheme introduced the concept
> of "exactness", and the type predicates such as 'real?',
> 'rational?' and
> 'integer?' are closer to their mathematical definitions than in CL and
> do not merely reflect the internal representation used.
>
> In Scheme, 3.0 is an integer (i.e. 'integer?' returns true and it is
> accepted by integer operations such as 'gcd'), but unlike 3 it is not
> an /exact/ integer (i.e. 'exact?' returns false). Similarly, 3.5 is
> 'rational?' but unlike 7/2 it is not an /exact/ rational.
>
> Note that here "exact" is being used in a different sense than Richard
> Fateman used above. Indeed, 3.0 does not represent an interval but
> rather a single number that is equal to 3.
>
> Quoting section 6.2.2 of the (pleasantly concise) R5RS Scheme
> standard:
>
> Scheme numbers are either exact or inexact. A number is exact if it
> was written as an exact constant or was derived from exact numbers
> using only exact operations. A number is inexact if it was
> written as
> an inexact constant, if it was derived using inexact ingredients, or
> if it was derived using inexact operations. Thus inexactness is a
> contagious property of a number.
>
> If two implementations produce exact results for a computation that
> did not involve inexact intermediate results, the two ultimate
> results
> will be mathematically equivalent. This is generally not true of
> computations involving inexact numbers since approximate methods
> such
> as floating point arithmetic may be used, but it is the duty of each
> implementation to make the result as close as practical to the
> mathematically ideal result.
>
> Rational operations such as '+' should always produce exact results
> when given exact arguments. If the operation is unable to
> produce an
> exact result, then it may either report the violation of an
> implementation restriction or it may silently coerce its result
> to an
> inexact value.
>
> In typical Scheme implementations, exactness is determined by the
> underlying representation used to store the number: for real numbers,
> flonums are inexact, and fixnums, bignums, and ratnums are exact.
> Complex numbers are exact if and only if both components are exact.
>
> Exactness can be tested using the predicates 'exact?' and 'inexact?'.
>
> Note that inexact integers such as 3.0 are accepted by integer
> arithmetic operators (e.g. 'gcd' and 'modulo'), but they are _not_
> accepted as indices into data structures (e.g. by 'vector-ref').
> The idea is to allow the construction of robust programs that are
> not vulnerable to round-off errors.
>
> I wonder if it might be desirable to somehow adapt some of these ideas
> into Maxima.
>
> Regards,
> Mark
>
>