This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Hi Brad,
many thanks for your comments! A few issues you raise seem
substantive, but I'm not expert enough on numerics to answer them.
(Will might search for his name in this email for follow-up bait.)
Bradley Lucier <lucier@xxxxxxxxxxxxxxx> writes:
> 1. In the first paragraph it says "The generic operations all
> implement inexact operations." What does that mean?
I'll leave this one to Will.
> 2. In the first paragraph it says "A number is inexact if it is
> infinite, if it was written as an inexact constant, if it was derived
> using inexact ingredients, or if it was derived using inexact
> operations."
> (a) I prefer some other word to "ingredients".
Which one?
> (b) What is an inexact operation? The in* functions? Or, do
> you mean every operation in this section?
I guess this could be clarified. It means every operation that, as
part of what it does, introduces error into the result. Note that
"operations" are distinct from "procedures." It's part of the nature
of the R5RS generic arithmetic that each procedures implements
multiple operations, depending on the arguments. The statement you're
referring to means operations performed by procedures that consume
exact arguments and can't return a mathematically exact result.
> (c) If 0 denotes exact 0 and 1 denotes exact 1, I prefer
> (log 1) = (sin 0)=(asin 0)=(atan 0)=(tan 0)=...=0
> and
> (cos 0) = (exp 0)=1,
> in the same way that I prefer (sqrt 4) = 2 (where 4 denotes
> exact 4 and 2 denotes exact 2). Is this allowed in your proposal?
I don't see why not. (It is not required, however.) I don't think it
was our intention to forbid it.
> 3. Paragraph 6 says "With the exception of inexact->exact, the
> operations described in this section must return inexact results when
> given any inexact arguments."
> (a) I prefer (* 0 x) => 0 for any x; is this allowed in your
> proposal?
No. I can't say I'm convinced by either you or Jaffer's argument
either way---maybe some other experts could cast their votes?
> 4. "nan?" takes any complex as an argument. If the real or
> imaginary part of z is a NaN, and the other is rational, does that
> make z a NaN?
> Maybe you should restrict the argument of nan? to be real.
Yes. Will do.
> 5. Re: "If any of these procedures are applied to mixed non-rational
> real and non-real complex arguments, they either report a violation
> of an implementation restriction or return an unspecified number."
> What does this mean? That
> (+ +nan.0 +4.0i)
> is not specified?
Yes.
> Are you allowing here an implementation to use the computable reals
> as the inexact representation?
I don't see what this statement has to do with it---the computable
reals sure should qualify as a representation for inexact reals,
though.
> 6. Perhaps you should remove strictly double argument "-" and "/"
> from the manual, since this case is subsumed into the case with two
> or more arguments.
Good point. Will do.
> 7. Why do "-" and "/" not have the commentary "If any of these
> procedures are applied to mixed non-rational real and non-real
> complex arguments, they either report a violation of an
> implementation restriction or return an unspecified number."?
Oversight. Will fix.
> 8. Integer Divison. [...]
> (c) This is one place where the Rationale says to refer to Egner
> et al. to see an argument why these procedures "are better suited
> than quotient and remainder to implement modular reduction." As a
> point of procedure, I would really prefer to have the arguments
> included in this document; I don't want to have to discuss my
> opinions of Egner et al. just to discuss my opinions of this specific
> proposal.
That is not going to happen---the draft refers to external documents
as a rationale on numerous issues. Moreover, this issue is pretty
isolated in the paper, and I don't see any problem with discussing
this specific issue, referring to the paper.
> 9. I don't agree that +inf.0, -inf.0, and +nan.0 should be in the
> domain of floor, round, ceiling, and truncate; returning these values
> as results implies, to me, that they are integers, and I believe they
> aren't integers, since they aren't rational.
This is on the issues list---I'm almost convinced, but wonder what
happens in representations where the argument isn't infinite or NaN,
and the result still can't be represented as an inexact integer. (Not
with IEEE 754, obviously, but possible in fixed-point
representations.) Signalling an error in this case would seem to make
a program susceptible to long-latent programming errors slash
portability problems.
> 11. Re: log, etc. You have the statement "If the function has a real-
> valued limit as its argument tends toward positive infinity, then
> that is the value returned by the function applied to +inf.0. If the
> function has a real-valued limit as its argument tends toward
> negative infinity, then that is the value returned by the function
> applied to -inf.0." Why are complex-valued limits not specified, too?
Oversight, I guess. I'm unsure how to do this right---could you
suggest language to help clean this up?
> Also, you have "In the event that these formulae do not yield a real
> result for the given arguments, the result may be +nan.0, or may be
> some meaningless inexact number." I don't understand the reason for
> this statement.
It specifies the case where the result is undefined.
> 12. (a) You give the examples:
> (log +inf.0) => +inf.0
> (log -1.0+0.0i) => 0.0+pii
> (log -1.0-0.0i) => 0.0-pii
> yet
> (log -inf.0) => unspecified
> Given the previous examples, shouldn't
> (log -inf.0) => +inf.0+pii
> (b) You don't say what (log 0) evaluates to; I would prefer it
> to be an error.
I'll have to defer these to a discussion with Will.
> 13. For sqrt: Is your intention to no longer have sqrt return exact
> results when possible given exact arguments?
No.
> Or will
> (sqrt 4) => 2
> be allowed? Your definition
> (sqrt z) => (exp (/ (log z) 2.0))
> seems to preclude it by putting in that inexact 2. Do you mean
> the right hand side of this formula literally, with exp and log being
> Scheme procedures, or do you mean to represent the mathematical
> formula $e^{\log(z)/2}$ (in TeX notation).
Good point. This (the relationship between mathematical formulae and
the return values of procedures) is a general problem with the
presentation, and (in different form) dates back to R5RS. It's my
intention to clean this up before it goes into R6RS.
> 13 bis: Again for sqrt, why is
> (sqrt -inf.0) => unspecified
> and not
> (sqrt -inf.0) => +inf.0i
> You didn't have any problem with
> (log 0.0) => -inf.0
I'll have to defer this to a discussion with Will.
> 14. About expt: In contrast to my comments about sqrt, I note that
> your definition of expt uses mathematical notation to define it, so
> (expt 5 3) => 125, not 125.0
> is not only allowed, but required?
Yes.
> Is
> (expt 125 1/3) => 5
> allowed?
Yes, but not required.
> 15. I agree with Knuth, and would very much prefer
> (expt 0 0) => 1
It does say that, but I see the example has a typo (the "1" is
missing). Will fix.
> 16. About magnitude: Following Kahan, I think it should be required
> that
> (magnitude z) => +inf.0
> if either the real or imaginary part of z is infinite (even if
> the other part is a NaN). Here Kahan is following the argument that,
> if the real or imaginary part is infinite, you would get the same
> answer no matter the (finite) value of the other part, so you should
> give that answer even if the other part is infinite or NaN.
I'll have to defer these to a discussion with Will.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla