From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#16365: (* 0 +inf.0) rationale is flawed Date: Tue, 21 Jun 2016 15:21:30 +0100 Message-ID: <20160621142130.GA1170@fysh.org> References: <20140106001719.GI21945@fysh.org> <87r3bqzpbd.fsf@pobox.com> <87vb12skz7.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1466518944 20138 80.91.229.3 (21 Jun 2016 14:22:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2016 14:22:24 +0000 (UTC) Cc: 16365@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Jun 21 16:22:17 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bFMZE-00057O-Q8 for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 16:22:16 +0200 Original-Received: from localhost ([::1]:52220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMZD-0004cU-Vk for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 10:22:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMZ5-0004a7-Ak for bug-guile@gnu.org; Tue, 21 Jun 2016 10:22:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFMZ0-0000bg-51 for bug-guile@gnu.org; Tue, 21 Jun 2016 10:22:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMZ0-0000bZ-1a for bug-guile@gnu.org; Tue, 21 Jun 2016 10:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bFMYz-000573-R6 for bug-guile@gnu.org; Tue, 21 Jun 2016 10:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 21 Jun 2016 14:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16365 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 16365-submit@debbugs.gnu.org id=B16365.146651889619618 (code B ref 16365); Tue, 21 Jun 2016 14:22:01 +0000 Original-Received: (at 16365) by debbugs.gnu.org; 21 Jun 2016 14:21:36 +0000 Original-Received: from localhost ([127.0.0.1]:49851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFMYa-00056M-6R for submit@debbugs.gnu.org; Tue, 21 Jun 2016 10:21:36 -0400 Original-Received: from river.fysh.org ([87.98.248.19]:43731 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFMYX-00056B-QC for 16365@debbugs.gnu.org; Tue, 21 Jun 2016 10:21:34 -0400 Original-Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian)) id 1bFMYU-00034A-24; Tue, 21 Jun 2016 15:21:30 +0100 Content-Disposition: inline In-Reply-To: <87vb12skz7.fsf@netris.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8097 Archived-At: Mark H Weaver wrote: > I also suspect that (/ 0 ) should be 0, >although that conflicts with R6RS. We should probably investigate the >rationale behind R6RS's decision to specify that (/ 0 0.0) returns a NaN >before changing that, though. I think R6RS makes sense for (/ 0 0.0). A flonum zero really represents a range of values including both small non-zero numbers and actual zero. The mathematical result of the division could therefore be either zero or undefined. To return zero for it would be picking a particular result, on the assumption that the flonum zero actually represented a non-zero value, and that's not justified. So to use the flonum behaviour seems the best thing available. (/ 0 3.5) is a different case. Here the mathematical result is an exact zero, and I'm surprised that R6RS specifies that this should be an inexact zero. This seems inconsistent with (* 1.0 0), for which it specifies that the result may be either 0 or 0.0. I'd also question R6RS in the related case of (/ 0.0 0). Mathematically this division is definitely an error, regardless of whether the dividend represents zero or a non-zero number. So it would make sense for this to raise an exception in the same manner as (/ 3 0) or (/ 0 0), rather than get flonum treatment as R6RS specifies. But deviating from R6RS, even with a good rationale for other behaviour, would be a bad idea. The questionable R6RS requirements are not crazy, just suboptimal. The case I originally raised, (* 0 +inf.0), is one for which R6RS offers the choice. -zefram