[Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Peter Bex
(10 Aug 2011 19:11 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
John Cowan
(10 Aug 2011 19:40 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Peter Bex
(04 Sep 2011 15:28 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Peter Bex
(04 Sep 2011 18:55 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Alex Shinn
(16 Aug 2011 16:23 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Peter Bex
(16 Aug 2011 16:29 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
John Cowan
(16 Aug 2011 16:56 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax Peter Bex (16 Aug 2011 18:41 UTC)
|
Re: [Scheme-reports] Padding/placeholders (hashes) in numerical syntax
Ray Dillinger
(17 Aug 2011 16:48 UTC)
|
On Tue, Aug 16, 2011 at 12:55:29PM -0400, John Cowan wrote: > Peter Bex scripsit: > > > How does that work? AFAIK there's no way to specify how many > > digits of precision you want, using standard procedures at least. > > R[23]RS had a bunch of syntactic forms that returned a private > object called a *format* which could be passed as the second > argument to number->string. For example, on an R3RS system > using 32-bit floats, (number->string 6.0238.10e23 (fix 2)) > evaluates to "6023800#################.##". For details see > http://people.csail.mit.edu/jaffer/r3rs_8.html#SEC51 . Wow, that's some strange stuff! Thanks for the link, I didn't think to investigate the old standards. > When the system of formats was removed from R4RS and the second > argument changed to a radix, the # numeric syntax was retained, > presumably so that old data files could still be read. Why not allows implementations to choose whether they want to be backwards compatible in this way? If # is not specified in the standard it can still be supported by individual implementations, right? By the way, I also noticed there's supposed to be support for exponent markers of various kinds: e, s, f, d and l (and their uppercase forms). The standard mentions something about short, single, double and long precision, but are there any Schemes that actually differentiate between these kinds of flonums? How do these forms interact with the #e prefix? If there are no Schemes that differentiate, that's another bit of historical cruft that could be scheduled to be deleted. Scheme48 and Chicken only seem to support the "e" there. MIT, Gauche, Guile and Racket accept all these characters (and I'll add it to the "numbers" egg too, soon, just for the sake of completeness). I don't know if these other Schemes assign any special meaning to the characters or if they're all treated the same. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports