This email contains preliminary responses to several recent emails,
in reverse order, ending with a question about the specification of
flexponent.

Arthur A. Gleckler corrected two errors in srfi-144-constants.scm
and wrote:

> Note also that the precision of these numbers is much less than that of the
> other numbers in the file.

In a few days, I'll be submitting another pull request that fixes
several problems with the sample implementations and also states
those two constants to the precision seen in the other constants.
For those who can't wait, the values are:

(define fl-4thrt-2    1.1892071150027210667174999705604759152930) ; fourthrt(2)
(define fl-1/log-phi  2.0780869212350275376013226061177957677422) ; 1/ln(phi)

John Cowan wrote:

> Will's investigations show that all but a few of the C functions
> duplicated in SRFI 144 aren't any faster than his Scheme equivalents.

That is clearly a Larceny-specific result.  Using an FFI to access
the corresponding C functions would be more advantageous in systems
whose FFI is faster than Larceny's or whose Scheme code runs less
quickly.

> I'm concerned that this will not be true on compile-to-C systems,
> where systems may be smart enough to output flsin, say, as a call
> to sin(), which is then open-coded by the C compiler.  Since Larceny
> calls C sin via its FFI, which bypasses such open-coding, this benefit
> is lost.

Compiler writers who want to generate special code for particular
procedures of SRFI 144 are free to do so.  In Larceny, for example,
the compiler already generates special code for many of these flonum
procedures because they're imported from (rnrs arithmetic flonums),
which has already been given some special attention and will now be
given more special attention because of SRFI 144 and the anticipated
R7RS Orange Edition.

Larceny uses several different mechanisms:

    open-coding  (e.g. fl+ and fl<?)
    millicode    (e.g. generic + and <)
    syscalls     (e.g. flonum cases for generic sin and sqrt)
    FFI          (e.g. current-jiffy on platforms with reliable FFI)
    closed calls (e.g. gcd, generic expt, rationalize)

I haven't yet decided which SRFI 144 procedures will be implemented
using which of those mechanisms in Larceny.

Adding that stuff to the sample implementation of SRFI 144 would be
counterproductive---it would just add Larceny-specific complexity
that's destined to change over time anyway.

Bradley Lucier reported some glaring inaccuracies in the hyperbolic
functions and wrote:

> I'm remarking only because you go to the trouble to provide Taylor
> series implementations for arguments close to zero for some functions.
> These functions could use something similar (or to express them in
> terms of flexp-1 or fllog1+, where you do give a careful Taylor series
> for small arguments).
> In general, it's not good to have values of x for which |asinh(x)|>x
> or |atanh(x)|>1.

Thank you.  I'm working to fix that for the next pull request I submit,
which should be within the next few days.

John Cowan wrote:

> Will, my only immediate comment is that I think it is better to
> implement the constants as literals

I have incorporated a corrected form of srfi-144-constants.scm into
the sample implementation.  That will be in my next pull request.

                                * * *

Now for the substantive question about draft #7.  I interpreted
the specification of flexponent to mean (flexponent x) returns
(fllog2 (flabs x)), which is a flonum but is seldom an integer.
During testing, I noticed that the C99 function logb, which is
mentioned by the specification of flexponent, always returns an
integer:

% ./larceny
Larceny v1.1a2 (Jun 16 2017 20:58:46, precise:Posix:unified)
larceny.heap, built on Fri Jun 16 21:00:04 EDT 2017

> (require 'std-ffi)
> (define logb (foreign-procedure "logb" '(double) 'double))
> (map logb '(-1.0 1.0 3.4 3.999 4.0))
(0.0 0.0 1.0 1.0 2.0)

If flexponent was intended to behave like logb, then its specification
should say it always returns an inexact integer when given a finite
flonum argument, truncating the base-2 logarithm of the absolute value
of its argument towards zero.

If flexponent was intended to behave like the composition of fllog2
and flabs, then its specification should warn that flexponent, unlike
logb, usually returns a non-integer.

Will