[r6rs-discuss] Hashes in the number syntax

From: Peter Gavin <pgavin>
Date: Wed Nov 22 09:32:46 2006

On 11/20/06, William D Clinger <will_at_ccs.neu.edu> wrote:
> Sounds good to me. If anyone wants to object to dropping
> that notation, now (i.e. before the next draft comes out)
> might be a good time.

I think it should be kept. I always figured that it was possible to
keep a precision field with inexact numbers, which could be used in
later computations. I think the way most (if not all) implementations
are currently treating it is wrong. That is,
10##.# is *not* the same as 1000.0, or 1050.0, or anything else. It
*actually* means some number between 1000.0 1099.999.... So an
implementation should store the number as "1.0e3, with an error on the
order of 1e2". The hashes should not be "thrown away". To do so
would be incorrect.

I don't think anyone's mentioned the affect uncertainty in numbers has
on numerical operations. If two uncertain measurements are taken, and
a computation is performed with them, the result should carry over the
uncertainty from the original measurements. For example,
(+ 123#.# 1542.#)
should have the result 277#.#. I haven't seen any implementation
actually *do* something like this, but I think it would be the most
correct way to do it.

I think its also important to note that (IMO, anyway) the correct way
to interpret an inexact number with no hashes should be with hashes
extending following the last digit, to infinity. That way smallish
inexact numbers can be expressed without using scientific notation.
For example, 1.5 and 1.5#### are equivalent; and also
(* 1.5 100.) should return either 15# or 1.5e2 (which would be equivalent).

One last thing, I think the reason the syntax isn't being found in
the public code repositories is because people try not to store data
in code; it's usually stored in external files. The type of numerical
data files I would see the hash syntax being most useful for are
usually gigantic (megabytes to gigabytes or more).

Pete
Received on Wed Nov 22 2006 - 09:32:33 UTC