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 William D Clinger 21 Jun 2017 21:08 UTC

Bradley Lucier wrote:

> 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.

> 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.

Come to think of it, that was why my previous version required base > 1.

If that's the biggest thing wrong with the sample implementation, I'll be
happy.

If there are other corrections I need to make, I'll enforce base > 1 when
I make those other corrections.  I don't think this justifies another pull
request all by its lonesome.

Will