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)
|
| 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.