On Fri, Aug 18, 2017 at 9:47 AM, William D Clinger <xxxxxx@ccs.neu.edu> wrote:

I believe that was a mistake in the text of the SRFI. Even if it wasn't,
it should be treated as a mistake because the least positive flonum is a
more useful constant than the most negative flonum.

I agree. This was a misunderstanding on my part that I never corrected.

Less importantly, SRFI 144 doesn't require flonums to use double precision
so it can't possibly be correct to mention DBL_MAX without also mentioning
FLT_MAX and LDBL_MAX. I will, however, perpetuate that minor error by
considering only the double precision constants in paragraphs below.

This is a general issue throughout the SRFI. For example, flsin mentions only C99 sin() without mentioning sinf() or sinl(). Given that every Scheme I have tested with the exceptions of Racket, Kawa, and NexJ supports only C doubles (if anything) as Scheme inexact reals, and even in these systems flonums are C doubles, I think it makes no practical difference.

Regardless of what SRFI 144 actually says, I believe the Scheme community
will be best served by defining fl-least as the minimum positive flonum,
which is likely to coincide with the C11 constant DBL_TRUE_MIN, not with
the C99 constants DBL_MIN.

Wikipedia says: "Some implementations of floating point units do not directly support denormal numbers in hardware, but rather trap to some kind of software support. While this may be transparent to the user, it can result in calculations which produce or consume denormal numbers being much slower than similar calculations on normal numbers."

I don't know if this is a live concern today, but if so, it may be necessary to support both constants so that tuned code can stay out of the denormalized range.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org

The man that wanders far from the walking tree

--first line of a non-existent poem by me