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