From: Mark H Weaver <mhw@netris.org>
To: bil@ccrma.Stanford.EDU
Cc: 30426@debbugs.gnu.org
Subject: bug#30426: division inconsistency?
Date: Thu, 15 Feb 2018 02:35:14 -0500 [thread overview]
Message-ID: <87inayogct.fsf@netris.org> (raw)
In-Reply-To: <7d3ad28781defb8921e66e6287581af8@ccrma.stanford.edu> (bil@ccrma.stanford.edu's message of "Wed, 14 Feb 2018 14:10:52 -0800")
Hi Bill,
bil@ccrma.Stanford.EDU writes:
> But if (* 0 x) is 0, you lose the notion that
> (* exact inexact) is inexact. So (* 0 +inf.0)
> should be 0.0 or maybe +nan.0. Similarly with
> +nan.0, I suppose.
No, because (* 0 x) is equivalent to (+), where the x is not an input.
In fact, this specific case (multiplication by exact 0) is given as an
example where exact 0 may be returned even if the other argument is
inexact, by R4RS, R5RS, R6RS, and R7RS.
R4RS section 6.5.2, and R5RS section 6.2.2 (Exactness), state:
With the exception of 'inexact->exact', the operations described in
this section must generally return inexact results when given any
inexact arguments. An operation may, however, return an exact result
if it can prove that the value of the result is unaffected by the
inexactness of its arguments. For example, multiplication of any
number by an exact zero may produce an exact zero result, even if the
other argument is inexact.
R6RS section 11.7.1 (Propagation of exactness and inexactness) states:
One general exception to the rule above is that an implementation may
return an exact result despite inexact arguments if that exact result
would be the correct result for all possible substitutions of exact
arguments for the inexact ones. An example is (* 1.0 0) which may
return either 0 (exact) or 0.0 (inexact).
R7RS section 6.2.2 (Exactness) states:
Except for exact, the operations described in this section must
generally return inexact results when given any inexact arguments. An
operation may, however, return an exact result if it can prove that
the value of the result is unaffected by the inexactness of its
arguments. For example, multiplication of any number by an exact zero
may produce an exact zero result, even if the other argument is
inexact.
Specifically, the expression (* 0 +inf.0) may return 0, or +nan.0, or
report that inexact numbers are not supported, or report that
non-rational real numbers are not supported, or fail silently or
noisily in other implementation-specific ways.
I'm quite sensitive to this issue, so sensitive that I decided to change
Guile several years ago so that (* 0 1.0) would return 0.0 instead of 0.
My rationale was that if the 1.0 were replaced by +inf.0 or +nan.0, then
by IEEE 754 the result should be +nan.0, and therefore that the result
was not the same regardless of the value of the inexact argument. I
didn't care that R[4567]RS specifically gave this as an example where an
exact 0 may be returned, because I judged that it violated the
principles of the exactness propagation, and I don't want to return an
exact result unless it could in principle be _proved_ to be correct.
The new language in R6RS is what changed my mind. In R6RS, you may
return an exact result if it "would be the correct result for all
possible substitutions of _exact_ arguments for the inexact ones." So,
we needn't consider what would happen if +inf.0 or +nan.0 were put in
place of the 1.0 in (* 0 1.0), because +inf.0 and +nan.0 are not exact.
I think this is the right principle. In mathematics, all real numbers
are finite; there are no infinities and no NaNs. I regard the inexact
infinities as merely inexact representations of very large finite real
numbers.
What do you think?
Regards,
Mark
prev parent reply other threads:[~2018-02-15 7:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 22:56 bug#30426: division inconsistency? bil
2018-02-12 21:01 ` Mark H Weaver
2018-02-12 21:15 ` Mark H Weaver
2018-02-12 21:59 ` bil
2018-02-14 20:54 ` Mark H Weaver
2018-02-14 22:10 ` bil
2018-02-15 7:35 ` Mark H Weaver [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inayogct.fsf@netris.org \
--to=mhw@netris.org \
--cc=30426@debbugs.gnu.org \
--cc=bil@ccrma.Stanford.EDU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).