Improving Dylan floating-point support
Peter S. Housel
[repost]
There are several features missing from Dylan's support for
floating-point arithmetic that I would consider essential for any sort
of numeric programming. I propose adding the following symbols to the
common-extensions module of common-dylan:
// Numerics
function decode-float (<float>) => (<float>, <integer>, <float>);
function scale-float (<float>, <integer>) => (<float>);
function float-radix (<float>) => (<integer>);
function float-digits (<float>) => (<integer>);
function float-precision (<float>) => (<integer>);
constant $single-float-epsilon :: <single-float>;
constant $double-float-epsilon :: <double-float>;
constant $extended-float-epsilon :: <extended-float>;
constant $minimum-single-float-exponent :: <integer>;
constant $maximum-single-float-exponent :: <integer>;
constant $minimum-double-float-exponent :: <integer>;
constant $maximum-double-float-exponent :: <integer>;
constant $minimum-extended-float-exponent :: <integer>;
constant $maximum-extended-float-exponent :: <integer>;
function finite? (<object>) => (<boolean>);
function infinite? (<object>) => (<boolean>);
// Formatting
function string-to-float
(<string>, #"key", #"start", #"end", #"default-class")
=> (<float>, <integer>);
The semantics of these follows that of the corresponding functions in
the ANSI Common Lisp standard
(http://www.lispworks.com/reference/HyperSpec/Body/f_dec_fl.htm).
Additional constants such as $most-positive-single-float and the like
(http://www.lispworks.com/reference/HyperSpec/Body/v_most_1.htm) were
omitted but could be added.
Support for NaN (Not a Number) was also omitted.
I plan on implementing these in Gwydion Dylan in the next few days.
Any comments or suggested additions would be appreciated.
-Peter-
Scott McKay
"Peter S. Housel" <hou...@cox.net> wrote in message
news:mu9r86y...@ip68-4-96-119.oc.oc.cox.net...
These all sound fine to me.
A serious blunder made in Dylan was the definition of only
\= and \< as generics, but not \>. In "real" math, these inequalities
form a trichotomy. In IEEE, they do not. NaNs (and maybe
infinities) require that all three be explicitly defined, since
"not >" does not imply either "=" or ">".
Scott Schwartz
> I plan on implementing these in Gwydion Dylan in the next few days.
> Any comments or suggested additions would be appreciated.
William Kahan (http://www.cs.berkeley.edu/~wkahan/) has had a lot to
say on the topic off floating point and programming languages. Maybe
some of his ideas apply to dylan?
Peter S. Housel
Of course Kahan has a lot of things to say that might apply, and his
presentation is always... interesting. Some references that might be
contain some easier-to-apply advice include:
* Goldberg, David. What Every Computer Scientist Should Know About
Floating-Point Arithmetic. ACM Computing Surveys 23, 1 (March 1991).
* Goldberg, David. The Design of Floating-Point Data Types. ACM Letters
on Programming Languages and Systems 1, 2 (June 1992).
* Hauser, John. Handling Floating-Point Exceptions in Numeric
Programs. ACM Transactions on Programming Languages and Systems 18, 2
(March 1996).
* ISO/IEC 10697:1994(E). Information Technology--Language Independent
Arithmetic--Part 1: Integer and Floating-Point Arithmetic.
* ISO/IEC 10967-2:2001. Information Technology--Language Independent
Arithmetic--Part 2: Elementary Numerical Functions.
The standards are somewhat expensive, but committee draft versions are
available on the working group's web site,
http://std.dkuug.dk/JTC1/SC22/WG11/.
-Peter-