[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] 6.2 numbers
- To: scheme-reports <scheme-reports@x>
- Subject: [Scheme-reports] 6.2 numbers
- From: Andy Wingo <wingo@x>
- Date: Thu, 19 May 2011 18:42:47 +0200
The initial note about numerical computation being neglected in lisps is
And actually, relative to the R6RS, this report does indeed neglect
important areas, like the behavior of negative zero in transcendental
functions, and the various nan/infinity interactions.
Perhaps this was the right choice for this report; I don't know.
Suggestion: If you don't want to specify everything there is to do
with -0.0 et al, suggest that implementors produce systems that behave
in accordance to the IEEE recommendations, and specifically that they
follow the recommendations of the R6RS. There's nothing wrong to
refer to it in this way.
Also: R6RS changed the spelling of the cumbersome "inexact->exact" and
"exact->inexact" to "exact" and "inexact", respectively. This is a
Suggestion: The report should promote the shorter spellings, and
recommend that implementations provide deprecated shims for
6.2.3 talks a lot about flonums, but does not (that I could see)
actually refer to what that means.
Suggestion: find a reference, in the case that there is not one already.
There are warnings about equality predicates for inexact numbers, but no
warning about nan.
Suggestion: mention nan, briefly.
It's cool that you adopted Taylor's division operators. To the extent
that all five sets, are useful, a sixth is useful as well, `centered/'
et al. See:
It's the same as div0-and-mod0 it seems. I don't claim to understand
all the arguments there, but Mark is fairly convincing.
Also there is a typo in (OPERATOR/) (p.28): an extra space before
The various div-and-mod operators could use some more examples. Modulo
and remainder get half a page, whereas the ones that you are often
interested in get no space. A table, perhaps? Perhaps Taylor should
publish his draft somewhere in some referenceable form.
The same "module procedure" concerns that I had before apply to the
"inexact module" and "complex module" procedures in this section.
R6RS extended `number->string' to take a third argument, "precision".
Perhaps this was already brought up on the list but if not, it might be
a good addition.
Scheme-reports mailing list