Will Clinger has sent several messages to the SRFI 144 mailing list, but he isn't a subscriber, so they haven't been delivered. I've asked him to subscribe, but I'm forwarding his messages below so that they won't be missed.

SRFI Editor

comments on latest draft *William D Clinger* 04 Jun 2017 04:13 UTC

Comments on draft at http://vrici.lojban.org/~cowan/temp/srfi-144.html fl-2/pi Two to the power pi does not seem like a particularly useful constant, and it has nothing to do with (C99 M_2_PI), which is twice the *reciprocal* of pi. fl-fast-fl+* What should be the value of this if fl+* is more accurate than the composition but slower? (That's a likely outcome if fl+* is implemented via an FFI but the composition is implemented by dumb compilation to machine code.) flmax, flmin Why are these in the "Predicates" section? The "fl-greatest or fl-least otherwise" at the end of the spec should be "fl-least or fl-greatest otherwise". flround The part about "rounding to even when x represents a number halfway between two integers" is better than, and therefore incompatible with, the rounding away from zero performed by the cited (C99 round), so the citation is misleading. fllog1+ Is this really supposed to return (log x)+1 ? If so, the reference to (C99 log1p) is misleading, because that function returns log(x+1). I think it's supposed to return log(x+1), but is more accurate than fllog for values of x near 0, as with log1p. flatan arctan(y/x) is not always equivalent to atan2(y,x), so something is wrong with this spec. Will Clinger

Re: comments on latest draftWilliam D Clinger05 Jun 2017 18:30 UTCI have started to work on a portable implementation of SRFI 144 that will not rely on any FFI and will import only R7RS small and the (rnrs arithmetic *) libraries of R6RS, making a few more assumptions such as IEEE arithmetic for inexact reals. (Creating this portable, FFI-independent implementation is something I have to do anyway because Larceny runs on some platforms for which no FFI is available.) Implementing the special functions will be a bit of work, but not unmanageable. Here are some more comments on the draft at http://vrici.lojban.org/~cowan/temp/srfi-144.html The spec for flnegative? refers to fl< instead of fl<? . The spec for flinteger-exponent says it returns "the same as flexponent as an exact integer", but that is not possible because flexponent usually returns a non-integer. Concerning the specs for flmax and flmin, I wrote: > The "fl-greatest or fl-least otherwise" at the end of the spec > should be "fl-least or fl-greatest otherwise". That's almost as wrong as the current draft. The phrase should be "(fl- fl-greatest) or flgreatest otherwise". Will ClingerRe: comments on latest draftWilliam D Clinger07 Jun 2017 03:48 UTCThis is my third set of comments on the draft at http://vrici.lojban.org/~cowan/temp/srfi-144.html Why must the argument to make-fllog-base be an exact integer? It would be a lot more useful *and* easier to implement if that argument were allowed to be any finite flonum greater than 1.0. The specification of flloggamma is incorrect. Its first return value should be log(|Gamma(x)|), not log(Gamma(|x|)). The spec for fl+* says it computes its result "as if to infinite precision and rounded only once." That's fine as an aspirational goal, but it's overly ambitious as a requirement. To implement it portably, or on hardware that doesn't have machine instructions that satisfy the requirement, satisfying the requirement probably involves conversion to an exact representation for the operations followed by conversion back to a flonum. That's going to be quite slow. If speed is one of this procedure's goals, as I gather from the discussion, the SRFI shouldn't impose absolute requirements that force implementors to make the procedure much slower (on some platforms) than the obvious composition. Will Clinger