From cowan at mercury.ccil.org  Sat Sep  8 20:49:14 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 8 Sep 2012 20:49:14 -0400
Subject: [r6rs-discuss] Daniel Weinreb
Message-ID: <20120909004914.GB19725@mercury.ccil.org>

Daniel Weinreb died yesterday.  I have added his name to John McCarthy's
as dedicatees of R7RS-small (unless I hear objections from the Working
Group or the Steering Committee).

There is a Boston Globe obituary at
http://www.legacy.com/obituaries/bostonglobe/obituary.aspx?pid=159710898
with provisions for comment.

-- 
John Cowan  cowan at ccil.org  http://ccil.org/~cowan
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
        --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)


From scheme at speechcode.com  Sat Sep  8 21:21:54 2012
From: scheme at speechcode.com (Arthur A. Gleckler)
Date: Sat, 8 Sep 2012 18:21:54 -0700
Subject: [r6rs-discuss] [scheme-reports-wg1] Daniel Weinreb
In-Reply-To: <20120909004914.GB19725@mercury.ccil.org>
References: <20120909004914.GB19725@mercury.ccil.org>
Message-ID: <CALnw4L+AoQhLzwxYjgG+BP6bJUx6uFPKy26V_kZ7i9XW3OmnFA@mail.gmail.com>

>
> Daniel Weinreb died yesterday.  I have added his name to John McCarthy's
> as dedicatees of R7RS-small (unless I hear objections from the Working
> Group or the Steering Committee).
>

That is a wonderful idea, John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20120908/73ecacab/attachment.htm 

From alexshinn at gmail.com  Wed Sep 19 23:35:00 2012
From: alexshinn at gmail.com (Alex Shinn)
Date: Thu, 20 Sep 2012 12:35:00 +0900
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <16367755.2435021345078255700.JavaMail.root@zimbra>
References: <23558945.2435001345078241594.JavaMail.root@zimbra>
	<16367755.2435021345078255700.JavaMail.root@zimbra>
Message-ID: <CAMMPzYMLffZQqZEzr6Dr8MA8w4_=CavzNSHytAFXe-6zvSt_tw@mail.gmail.com>

One more thing - how was (expt 0 z) extended to
return 0 for complex z?  The approaches I've tried
would result in NaN, and indeed this seems to be
what most implementations return.

-- 
Alex

On Thu, Aug 16, 2012 at 9:50 AM,  <will at ccs.neu.edu> wrote:
> Alex Shinn wrote:
>
>> What I'm more interested in is the unusual behavior
>> that the result _either_ raises an exception _or_ returns
>> an unspecified number.  I believe this is the only place
>> in any of the reports where the semantics is the disjunction
>> of signalling an error and an unspecified value.  What's
>> the story behind this?
>
> I don't remember, but here's what I suspect.
>
> In the R5RS and earlier, the phrase "is an error" was used to
> mean implementations were allowed to signal an error or to
> return an arbitrary value, at their discretion.  In the R6RS,
> the "is an error" phrases were removed.  Most of those phrases
> turned into "an exception is raised", which represented a change
> from the R5RS semantics, but not here.  In this particular case,
> the new language appears to be an attempt to preserve some of
> the meaning of the R5RS "is an error" semantics.
>
> So I believe the language here is unusual because attempting
> to preserve R5RS "is an error" semantics was unusual.
>
> Will


From will at ccs.neu.edu  Thu Sep 20 11:08:57 2012
From: will at ccs.neu.edu (will at ccs.neu.edu)
Date: Thu, 20 Sep 2012 11:08:57 -0400 (EDT)
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <3483027.350401348153670603.JavaMail.root@zimbra>
Message-ID: <6180777.350421348153737928.JavaMail.root@zimbra>

Alex Shinn wrote:

> One more thing - how was (expt 0 z) extended to
> return 0 for complex z?  The approaches I've tried
> would result in NaN, and indeed this seems to be
> what most implementations return.

You may be misinterpreting the R6RS.  (expt 0 z) returns zero
if the real part of z is positive.  If z is zero, then it's
supposed to return zero.  If z is non-zero and its real part
is zero or negative, then implementations are free to return
whatever number object they like, or to raise an exception
with condition type &implementation-restriction.

Implementation is straightforward.  Here is Larceny's code:

(define (expt x y)

  ; x is nonzero, and y is an exact natural number.                             

  (define (e x y)
    (cond ((= y 0)
           1)
          ((odd? y)
           (* x (e x (- y 1))))
	  (else
           (let ((v (e x (quotient y 2))))
             (* v v)))))

  (cond ((zero? x)
         (let ((result (cond ((= y 0) 1)
                             ((> (real-part y) 0) 0)
                             (else +nan.0))))
           (if (and (exact? x) (exact? y))
               result
               (exact->inexact result))))
	((and (exact? y) (integer? y))
         (if (negative? y)
             (/ (expt x (abs y)))
	     (e x y)))
        (else
         (exp (* y (log x))))))

Will


From alexshinn at gmail.com  Thu Sep 20 11:18:56 2012
From: alexshinn at gmail.com (Alex Shinn)
Date: Fri, 21 Sep 2012 00:18:56 +0900
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <6180777.350421348153737928.JavaMail.root@zimbra>
References: <3483027.350401348153670603.JavaMail.root@zimbra>
	<6180777.350421348153737928.JavaMail.root@zimbra>
Message-ID: <CAMMPzYPTsnx=gY80N-jmB2KRQQPG08sQpM5-bVpZPyC8MJg6VA@mail.gmail.com>

Hi Will,

On Fri, Sep 21, 2012 at 12:08 AM,  <will at ccs.neu.edu> wrote:
> Alex Shinn wrote:
>
>> One more thing - how was (expt 0 z) extended to
>> return 0 for complex z?  The approaches I've tried
>> would result in NaN, and indeed this seems to be
>> what most implementations return.
>
> You may be misinterpreting the R6RS.

I may indeed :)

> (expt 0 z) returns zero
> if the real part of z is positive.  If z is zero, then it's
> supposed to return zero.  If z is non-zero and its real part
> is zero or negative, then implementations are free to return
> whatever number object they like, or to raise an exception
> with condition type &implementation-restriction.

The question has to do with non-real z with positive
real part, i.e. (expt 0.0 c+di), c > 0, d != 0.  As a
simplification I can see how it would be useful to
simply define this to be 0, but it can't be derived as
far as I can see from the definition of complex
exponentiation, w^z = e^(z log(w)), because log(0)
is undefined.  Existing implementations also differ
in their results here.

-- 
Alex

> Implementation is straightforward.  Here is Larceny's code:
>
> (define (expt x y)
>
>   ; x is nonzero, and y is an exact natural number.
>
>   (define (e x y)
>     (cond ((= y 0)
>            1)
>           ((odd? y)
>            (* x (e x (- y 1))))
>           (else
>            (let ((v (e x (quotient y 2))))
>              (* v v)))))
>
>   (cond ((zero? x)
>          (let ((result (cond ((= y 0) 1)
>                              ((> (real-part y) 0) 0)
>                              (else +nan.0))))
>            (if (and (exact? x) (exact? y))
>                result
>                (exact->inexact result))))
>         ((and (exact? y) (integer? y))
>          (if (negative? y)
>              (/ (expt x (abs y)))
>              (e x y)))
>         (else
>          (exp (* y (log x))))))
>
> Will


From will at ccs.neu.edu  Thu Sep 20 11:39:41 2012
From: will at ccs.neu.edu (will at ccs.neu.edu)
Date: Thu, 20 Sep 2012 11:39:41 -0400 (EDT)
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <18391878.351461348155547302.JavaMail.root@zimbra>
Message-ID: <28489120.351481348155581657.JavaMail.root@zimbra>

Alex Shinn wrote:

> The question has to do with non-real z with positive
> real part, i.e. (expt 0.0 c+di), c > 0, d != 0.  As a
> simplification I can see how it would be useful to
> simply define this to be 0, but it can't be derived as
> far as I can see from the definition of complex
> exponentiation, w^z = e^(z log(w)), because log(0)
> is undefined.

I haven't looked to see whether any rationale for this has been
published or recorded, and I won't try to guess.

> Existing implementations also differ in their results here.

Although some implementors of the R6RS may have principled
reasons for implementing expt in non-conforming fashion, I
can't imagine what those reasons might be and I haven't heard
of any such reasons.  I suspect you're talking about mere
bugs in those existing implementations of the R6RS.

I could list a great many bugs that I've found in existing
implementations of R6RS arithmetic.  Could you explain why
you want to discuss these particular bugs?

Will


From r6rsguy at free-comp-shop.com  Thu Sep 20 18:44:22 2012
From: r6rsguy at free-comp-shop.com (r6rsguy at free-comp-shop.com)
Date: Thu, 20 Sep 2012 18:44:22 -0400
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <6180777.350421348153737928.JavaMail.root@zimbra>
	(will@ccs.neu.edu)
References: <6180777.350421348153737928.JavaMail.root@zimbra>
Message-ID: <201209202244.q8KMiMq3003602@localhost.localdomain>

> From: will at ccs.neu.edu
> 
> You may be misinterpreting the R6RS.  (expt 0 z) returns zero
> if the real part of z is positive.  If z is zero, then it's
> supposed to return zero.


From will at ccs.neu.edu  Thu Sep 20 20:23:04 2012
From: will at ccs.neu.edu (will at ccs.neu.edu)
Date: Thu, 20 Sep 2012 20:23:04 -0400 (EDT)
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <11927202.362521348186785714.JavaMail.root@zimbra>
Message-ID: <25696779.362581348186983961.JavaMail.root@zimbra>

Keith (r6rsguy) wrote:

> > From: will at ccs.neu.edu
> > 
> > You may be misinterpreting the R6RS.  (expt 0 z) returns zero
> > if the real part of z is positive.  If z is zero, then it's
> > supposed to return zero.
> 
> From R6RS page 45:
>   0.0^z is 1.0 if z=0.0
> 
> You frightened me for a second.

My third "zero" in what you quoted should have been "one".  Thank
you for that correction.

Will


From alexshinn at gmail.com  Thu Sep 20 22:12:18 2012
From: alexshinn at gmail.com (Alex Shinn)
Date: Fri, 21 Sep 2012 11:12:18 +0900
Subject: [r6rs-discuss] rationale for expt
In-Reply-To: <28489120.351481348155581657.JavaMail.root@zimbra>
References: <18391878.351461348155547302.JavaMail.root@zimbra>
	<28489120.351481348155581657.JavaMail.root@zimbra>
Message-ID: <CAMMPzYMExz0KqSsaWqvV-wfa5VeiEKUv1F7ef+TR9EEa3J1h-Q@mail.gmail.com>

On Fri, Sep 21, 2012 at 12:39 AM,  <will at ccs.neu.edu> wrote:
>
> Although some implementors of the R6RS may have principled
> reasons for implementing expt in non-conforming fashion, I
> can't imagine what those reasons might be and I haven't heard
> of any such reasons.  I suspect you're talking about mere
> bugs in those existing implementations of the R6RS.
>
> I could list a great many bugs that I've found in existing
> implementations of R6RS arithmetic.  Could you explain why
> you want to discuss these particular bugs?

I'm following up on a complaint on the scheme-reports
public discussion list.  The R7RS formal comments
period is over, but we're still getting a trickle of informal
comments.

When comparing implementations I'm also looking at
R5RS implementations.  However in the absence of
either a mathematical basis or rough consensus among
implementations, I'm hard-pressed to defend this
change.

-- 
Alex


From cowan at mercury.ccil.org  Fri Sep 28 14:23:08 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 28 Sep 2012 14:23:08 -0400
Subject: [r6rs-discuss] Updated list of latest Scheme releases
Message-ID: <20120928182308.GA17606@mercury.ccil.org>

I have updated http://trac.sacrideo.us/wg/wiki/SchemeImplementationReleases
to contain the dates and version numbers for the latest stable releases
of the 45 Schemes currently in my test suite.  Where there doesn't seem to
be a stable release, I have tried to find the latest release available.

Please post any corrections.  Thanks.

-- 
Newbies always ask:                             John Cowan
  "Elements or attributes?                      http://www.ccil.org/~cowan
Which will serve me best?"                      cowan at ccil.org
  Those who know roar like lions;
  Wise hackers smile like tigers.                   --a tanka, or extended haiku