# Re: string->number

This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.

``` | From: Thomas Bushnell BSG <tb@xxxxxxxxxx>
| Date: Thu, 02 Jun 2005 19:08:56 -0700
|
| Aubrey Jaffer <agj@xxxxxxxxxxxx> writes:
|
| >  | From: Thomas Bushnell BSG <tb@xxxxxxxxxx>
| >  | Date: Thu, 02 Jun 2005 13:05:29 -0700
| >
| > ...  My point is that inexact numbers correspond to real number
| > neighborhoods; and hence have finite precision.
|
| Ok, that's fine.  I agree completely with what you've said about
| *inexact* numbers.
|
| ... I think that a Scheme implementation may also extend the nature
| of an external representation if it wishes, provided it keeps
| numbers separate from identifiers for all programs, in the right
| way.
|
| In other words, an implementation can invent a new syntax, say #s,
| where #sNNNN is the square root of NNNN, exact iff NNNN is.  For a
| great many of the standard operations of Scheme, this exactness can
| be easily preserved with a straightforward implementation.

I am having difficulty with inexact square-root numbers.  The real
numbers have a total ordering.  So for any two real numbers x1 and x2,
either x1 < x2, x1 > x2, or x1 = x2.

#s2. splits the 1.4142135623730951 neighborhood into three parts; lets
call them #s2.-, #s2., and #s2.+.  Because

"... it is the duty of each implementation to make the result as
close as practical to the mathematically ideal result",

1.414213562373095048801689 must map to #s2., while 1.4142135623730951
maps to #s2.+.  The split neighborhoods must be distinguished from
each other because of the total ordering.  But a floating-point
representation has no additional bits to encode which side of which
square-root any particular floating-point value is.

Thus inexact square-root numbers and inexact floating-point
representation are incompatible.

| NUMBER->STRING must produce this representation, and STRING->NUMBER
| must be able to handle it, and it should work the same as READ and in
| program text.  Such an extension is fully allowed by R5RS.
|
| If you argue that external representations for numbers CANNOT be
| extended, then you can make no sense of the explicit statements in the
| standard and the rationale for supporting exact numbers of just this
| sort.

Polar representation works because the polar coordinates of Real
numbers are in one-to-one correspondence with the Real numbers.
But one cannot casually add new inexact representations.

```