[Openmcl-devel] double floats

[Gary Byers]

On Tue, 1 Oct 2002, John DeSoi wrote:

> If I try to use the number 1.5e50 (e.g. just by typing it at the lisp
> prompt and hitting return) I get and exponent overflow error while
> executing CCL::FLOAT-AND-SCALE-AND-ROUND. I thought it might be a bug
> since it works in MCL. I see that what I need to do here for OpenMCL
> is explicitly say it is a double float with 1.5d50 (which returns
> 1.5d50 in OpenMCL and 1.5e50 in MCL). I also find it strange that in
> OpenMCL (= 1.5e10 1.5d10) is NIL but T in MCL.
>
> Thanks,

There aren't too many times that I can say this, but:

This is mentioned (as an "intentional difference between MCL/OpenMCL") on
the website FAQ.  I suppose that it wouldn't hurt to review some of the
implications of that difference.

CL provides 4 standard subtypes of FLOAT (SHORT-FLOAT, SINGLE-FLOAT,
DOUBLE-FLOAT, LONG-FLOAT), but gives the implementation some
discretion as to how these types are mapped to one or more concrete
floating-point types.  This issue is discussed in some detail in

../HyperSpec/Body/typ_short-flo_m_long-float.html

especially the section right after Figure 12-12.

Both MCL and OpenMCL provide two concrete float types (corresponding to
the IEEE Single and IEEE Double floats supported by the hardware.)

MCL partitions these so that the CL type SHORT-FLOAT corresponds to the 32-bit
IEEE single type and the types SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT correspond
to the 64-bit IEEE double type.

OpenMCL uses IEEE single floats to represent the CL SHORT-FLOAT and SINGLE-FLOAT
types and IEEE double floats to represent DOUBLE-FLOAT and LONG-FLOAT.

Note also that the type of floating-point constants written without an
explicit exponent marker (and the type of constants written with an 'e' marker)
is determined by the value of *READ-DEFAULT-FLOAT-FORMAT*, which defaults to
SINGLE-FLOAT.

If I had a nickel for every time that an MCL user expressed confusion over the
fact that a SINGLE-FLOAT was an IEEE double, ... well, I might have a dollar or
two.  I know that the issue's come up on info-mcl a few times in the last year,
and people used to file well-intentioned bug reports on a fairly regular basis.
(I think that the partitioning scheme used by OpenMCL and many other implentations
is a better choice, but MCL's scheme is explicitly permitted by the standard.)

When IEEE single floats were added to PPC MCL, the decision was made to -not-
change the meaning of the type SINGLE-FLOAT until users had had some time
to get used to the idea of explicitly qualifying float constants.  I believe
that the release notes for that version suggested that the FP partitioning
scheme would change (to match that used by OpenMCL) in a future release.  As
far as I know, that's still the plan.


>
> John DeSoi, Ph.D.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel