Re: # in place of a digit.

[KenD@apple.com (Ken Dickey)]

At  4:34 PM 12/2/94 -0500, David Carlton wrote:
>A friend of mine posed the following question:
>
>Without testing it on a Scheme implementation, what does '18#' refer
>to, and where in R4RS is this explained clearly?

I believe that it should *appear* the same as (exact->inexact 180).  My
reasoning is that the language implementation cannot know what the error
distribution is.  The user can know and type in an extra digit or use a
rule such as "round toward even".  Having an implementation auto-magically
refine numbers does not sound like a good solution to me {even though this
frequently happens in decimal->binary conversion anyway}.

The preferred solution (IMHO) is to distinguish, as Mathematica does,
between machine numbers and better approximations to the reals and to allow
the user to specify range (180+/-2) or interval ([178,182.3]) and have some
control of precision and accuracy.  {Precision can be thought of as how
many digits, e.g. 3.1416287489327483748329; accuracy can be thought of as
how many digits are accurate, e.g. 3.141~6}.  Skeel & Keiper has a good
discussion of this (refs below).

>So what was the intent here?

The intent is to allow Scheme implementors a great deal of flexability in
implementation.  E.g. somebody can do an interpreter which only handles
integers but follows the report and be called "Scheme".  One can also do a
fine optimizing compiler and implement the full numeric tower (possibly
with extensions, e.g. interval numbers).  Unfortunately this is a case
where portability suffers.  On the other hand this can be driven by user
demand for features as well [e.g. Buy commercial implementations and demand
better numerical support rather than complain that ones local free-ware
does not have it; Change/'fix' the code and get the author(s) to fold it
back in to the source base].

>Is Scheme 48's return value one correct possibility?
I don't believe that the standard precludes this, but I would consider it
broken.

>In either case, has anybody ever used this syntax?
I must admit that I have not, however I don't typically deal with physical
measurements either.  The syntax does allow an implementation the ability
to track accuracy, which--if you can get at it--is helpful in error
analysis.

Cheers,
-Ken
===============Interesting readings===============

Skeel & Keiper: _Elementary Numerical Computing with Mathematica_, McGraw
Hill, 1993, ISBN 0-07-057820-6.

Aberth, _Precise Numerical Analysis_, W.C.Brown, 1988, ISBN 0-697-06760-2.

Goldberg: "What every computer scientist should know about floating-point
arithmetic", ACM Computing Surveys 23, 1991.

Walls, editor: _Improving Floating Point Programming_, Wiley, 1990, ISBN
0-471-92437-7.

Hatton & Roberts: "How Accurate Is Scientific Software?", IEEE Trans. SW
Engineering, v20, #10, October 1994.

---
There is also precision to be gained via constructive mathematics and
partial evaluation (E.g. see:
Roylance: "Expressing Mathematical Routines Constructively": L&FP '88,
Halifant & Sussman: "Abstraction in Numerical Methods": L&FP '88,
Berlin: "Partial Evaluation Applied to Numerical Computation": L&FP '90
).
                      --- E O F ---