Re: infinities reformulated Chongkai Zhu (31 May 2005 07:17 UTC)
Re: infinities reformulated Aubrey Jaffer (31 May 2005 23:47 UTC)
Re: infinities reformulated Thomas Bushnell BSG (02 Jun 2005 15:23 UTC)
Re: infinities reformulated Aubrey Jaffer (02 Jun 2005 16:12 UTC)
Re: infinities reformulated Thomas Bushnell BSG (02 Jun 2005 16:16 UTC)
string->number Aubrey Jaffer (02 Jun 2005 19:10 UTC)
Re: string->number Thomas Bushnell BSG (02 Jun 2005 20:05 UTC)
Re: string->number Aubrey Jaffer (03 Jun 2005 01:59 UTC)
Re: string->number Thomas Bushnell BSG (03 Jun 2005 02:09 UTC)
Re: string->number Aubrey Jaffer (15 Jun 2005 21:10 UTC)
Re: string->number Thomas Bushnell BSG (16 Jun 2005 15:28 UTC)
Re: string->number bear (16 Jun 2005 16:59 UTC)
Re: string->number Aubrey Jaffer (17 Jun 2005 02:16 UTC)
Re: infinities reformulated bear (04 Jun 2005 16:42 UTC)
Re: infinities reformulated Aubrey Jaffer (17 Jun 2005 02:22 UTC)
Re: infinities reformulated bear (19 Jun 2005 17:19 UTC)
Re: infinities reformulated Aubrey Jaffer (20 Jun 2005 03:10 UTC)
Re: infinities reformulated bear (20 Jun 2005 05:46 UTC)
precise-numbers Aubrey Jaffer (26 Jun 2005 01:50 UTC)

string->number Aubrey Jaffer 02 Jun 2005 19:10 UTC

 | From: Thomas Bushnell BSG <xxxxxx@becket.net>
 | Date: Thu, 02 Jun 2005 09:16:37 -0700
 |
 | Aubrey Jaffer <xxxxxx@alum.mit.edu> writes:
 |
 | > To first order:
 | >
 | >   (define (precision-of x) (string-length (number->string x)))
 | >
 | > R5RS requires all numbers to have external representations; and it
 | > specifies the allowed formats.
 |
 | What?  number->string does not specify the allowed formats for
 | exact numbers, only for inexact (and only for some inexact numbers

Yes, I should have written "inexact numbers".

 | at that).  This isn't an accident; it was done specifically for
 | just this reason, to allow for different representations.  See the
 | Rationale:
 |
 | "The unspecified case allows for infinities, NaNs, and non-flonum
 | representations."
 |
 | So if X is an exact version of sqrt 2, it's perfectly fine for
 | number->string to return anything that string->number can
 | understand.

Can number->string return a string which can't be READ as a number?

I had thought that 6.2.4 "Syntax of numerical constants" and 7.1.1
"Lexical structure" applied to the results of NUMBER->STRING.  If they
are independent, a note about that should be added to the report.