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 draft William D Clinger 05 Jun 2017 18:30 UTC
I 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 Clinger

Re: comments on latest draft William D Clinger 07 Jun 2017 03:48 UTC
This 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