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.
Corrected to 2/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.)
Accuracy has been removed from the definition in favor of speed only.
flmax, flmin: Why are these in the "Predicates" section?
Moved back to the beginning of the "Arithmetic" section.
The "fl-greatest or fl-least otherwise" at the end of the spec
should be "fl-least or fl-greatest otherwise".
See below.
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.
This now appears as a discussable issue.
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.
Corrected to log(x+1).
flatan
arctan(y/x) is not always equivalent to atan2(y,x), so
something is wrong with this spec.
Unfortunately, the wording of Posix is plain: "Upon successful
completion, these functions shall return the arc tangent of y/ x
in the range [π-,π] radians." Various special cases are then
stated, for which see
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.
This is excellent news!
The spec for flnegative? refers to fl< instead of fl<?
Fixed.
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.
Changed to "truncated to an exact 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".
Fixed accordingly.
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.
What is the utility of a non-integer base other than e,
which is already provided for? (The two mathematicians
who share my space speculated a bit about the
possible utility of log to the base phi.)
The specification of flloggamma is incorrect. Its first return
value should be log(|Gamma(x)|), not log(Gamma(|x|)).
Fixed.
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.
Being an ignoramus on this subject, I point you to
which I readily found by googling.
The SRFI shouldn't impose absolute requirements
that force implementors to make the procedure much slower (on some
platforms) than the obvious composition.
The C library does so, and gives you a flag (as I do also) to
warn you off if you can't afford to expend the time. Note that the
"obvious composition" does not always produce the same result,
due to the rounding. C fma() must be correct up to rounding,
but can be slow if necessary.
You're a brave man! Go and break through the lines, and remember while
you're out there risking life and limb through shot and shell,
we'll be in here thinking what a sucker you are! --Rufus T. Firefly