SRFI 144: more improvements to implementation Arthur A. Gleckler (20 Jun 2017 21:48 UTC)
Re: SRFI 144: more improvements to implementation Arthur A. Gleckler (20 Jun 2017 21:53 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (20 Jun 2017 23:29 UTC)
Re: SRFI 144: more improvements to implementation Arthur A. Gleckler (21 Jun 2017 00:10 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 01:39 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 21:01 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 21:20 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 20:32 UTC)
Re: SRFI 144: more improvements to implementation Bradley Lucier (21 Jun 2017 20:50 UTC)
Re: SRFI 144: more improvements to implementation Bradley Lucier (21 Jun 2017 20:50 UTC)
Re: SRFI 144: more improvements to implementation William D Clinger (21 Jun 2017 21:08 UTC)
Re: SRFI 144: more improvements to implementation John Cowan (21 Jun 2017 21:22 UTC)

Re: SRFI 144: more improvements to implementation Bradley Lucier 21 Jun 2017 20:48 UTC

> On Jun 21, 2017, at 4:32 PM, William D Clinger <xxxxxx@ccs.neu.edu> wrote:
>
> I have done so in a new pull request.
>
> That pull request also fixes the brain fart spotted by Bradley Lucier.

I’ve been thinking more about what the second argument of fllog could be.

Because (fllog a b) is presumably intended to be (/ (fllog a) (fllog b)), we need (fllog b) to be nonzero, i.e., b not equal to 1.

R6RS doesn’t say anything about the second argument that I could see.

Common lisp *defines* (log a b) = (log a)/(log b), with the associated branch cuts, so (log a 1.) would be (log a)/(+0.)=+inf.0, -inf.0, or +nan.0, depending on what (log a) is.

We’re defining something new here; if 0<b<1 then (fllog a b) is well defined, but maybe not so useful, so perhaps the second argument should be restricted to be > 1.

Brad