suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

minor edits to to strnum.ss comments and LOG. rebuilt boot files.

Browse Source 
original commit: 57a32da75084ff7baf5f6f290c1b0afc75230756
This commit is contained in:
dybvig 2016-05-01 21:33:49 -04:00
parent 83f6c935e9
commit 5299f8c14e
2 changed files with 38 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
LOG
View File

@ -62,7 +62,7 @@
- fixed incorrect handling of library-extension when searching wpo files
compile.ss,
7.ms
- modified floatify_normalize to properly round denormalized results and
- modified floatify_normalize to properly round denormalized results.
obviated scale_float in the process.
number.c,
ieee.ms
@ -73,16 +73,16 @@
restriction (among the other usual lexical condition types), and
string->number now raises #f, for #e<m>@<a>, where <m> and <a> are
nonzero integers, since Chez Scheme can't represent polar numbers other
than 0@<a> and <m>@0 exactly. <m>@<a> still produces an inexact result,
than 0@<n> and <n>@0 exactly. <m>@<a> still produces an inexact result,
i.e., we're still extending the set of inexact numeric constants beyond
what R6RS dictates. doing this required a rework of $str->num, which
turned into a fairly extensive rewrite that fixed up a few other minor
issues (like r6rs:string->number improperly allowing 1/2e10) and
eliminated the need for consumers to call $str->num twice in cases
where it actually produces a number. added some related new tests,
including several found lacking by profiling. added a couple of
checks to number->string whose absence was causing argument errors to
be reported by other routines.
where it can actually produce a number. added some related new tests,
including several found missing by profiling. added a couple of
checks to number->string the absence of which was causing argument
errors to be reported by other routines.
strnum.ss, exceptions.ss, read.ss
5_3.ms, 6.ms, root-experr*, patch*
- added pdtml flag, which if set to t causes profile-dump-html to be

50
s/strnum.ss
View File

@ -40,8 +40,8 @@ Possible options include:
(B) Treat each subpart as exact or inexact in isolation and use the
usual rules for preserving inexactness when combining the subparts.
Apply inexact to the result if #i is present and exact
to the result if #e is present.
Apply inexact to the result if #i is present and exact to the
result if #e is present.
(C) If #e and #i are not present, treat each subpart as exact or inexact
in isolation and use the usual rules for preserving inexactness when
@ -58,44 +58,40 @@ We take "zero denomintor" here to mean "exact zero denominator", and
treat, e.g., #i1/0, as +inf.0.
A B C
0/0 #f #f #f
1/0 #f #f #f
#e1/0 #f #f #f
#i1/0 +inf.0 #f +inf.0
1/0+1.0i +nan.0+1.0i #f #f
1.0+1/0i 1.0+nan.0i #f #f
#e1e1000 (expt 10 1000) #f (expt 10 1000)
0@1.0 0.0+0.0i 0 0
1.0+0i 1.0+0.0i 1.0 1.0
This code implements Option C and returns #f instead of signaling an
error whenever a syntactically valid number cannot be represented.
It computes inexact components with exact arithmetic where possible,
however, before converting them into inexact numbers, to insure the
greatest possible accuracy.
This code implements Option C. It computes inexact components with
exact arithmetic where possible, however, before converting them into
inexact numbers, to insure the greatest possible accuracy.
Rationale for Option C: B and C adhere most closely to the semantics of
the individual / and make-rectangular operators, and neither requires that
we scan the entire number first (as with A) to determine the (in)exactness
of the result. C takes into account the known (in)exactness of the
result to represent some useful values that B cannot, such as #i1/0 and
#e1e1000.
the individual / and make-rectangular operators, sometimes produce exact
results when A would produce inexact results, and do not require a scan
of the entire number first (as with A) to determine the (in)exactness of
the result. C takes into account the known (in)exactness of the result
to represent some useful values that B cannot, such as #i1/0 and #e1e1000.
R6RS doesn't say is what string->number should return for syntactically
valid numbers (other than exact numbers with a zero denominator) for
which the implementation has no representation, such as exact 1@1 in
an implementation that represents complex numbers in rectangular form.
Options include returning an approximation represented as an inexact
number (so that the result, which should be exact, isn't exact),
returning an approximation represented as an exact number (so that the
approximation misleadingly represents itself as exact), or to admit an
implementation restriction. We choose the to return an inexact result
for 1@1 (extending the set of situations where numeric constants are
implicitly inexact) and treat #e1@1 as an implementation restriction,
with string->number returning #f and the reader raising an exception
with condition type &implementation-restriction.
which the implementation has no representation, such as exact 1@1 in an
implementation such as Chez Scheme that represents all complex numbers in
rectangular form. Options include returning an approximation represented
as an inexact number (so that the result, which should be exact, isn't
exact), returning an approximation represented as an exact number (so
that the approximation misleadingly represents itself as exact), or to
admit an implementation restriction. We choose the to return an inexact
result for 1@1 (extending the set of situations where numeric constants
are implicitly inexact) and treat #e1@1 as violating an implementation
restriction, with string->number returning #f and the reader raising
an exception.
|#
(let ()