These routines were produced by someone who is not a great authority on
floating point, and may not be entirely correct. Where possible I tested
the special cases for routines.
The directory testieee contains test programs for IEEE-format machines.
I took a stab at making them work on the vax, but gave up as dealing with
exceptions (e.g. underflow, overflow, reserved operand) was just too tedious.
Note: it is possible to build a library with MACHINE=ieee but a couple
of warnings:
Be careful when compiling floor.c. These routines rely on
certain variables being only double precision. If these
variables are placed in 68881 registers, they will be extended
precision and the routines will produce incorrect results.
Unless your compiler does its own register allocation, this
is not likely to be a problem as none of the variables in
question are declared "register". If you are using GCC
you can specify -ffloat-store to avoid this problem.
The C version of drem() in ieee/support.c appears to compute
the incorrect results for drem(+-1, +-2). It yields 1 when
it should be -1 and -1 when it should be 1. "should be" is
based on what the VAX version yields and by cranking through
the formula.
If you do build using MACHINE=ieee and run the tests in testieee you
will note that some routines return errors:
floor/ceil/rint report that they got 0 when expecting -0.
Don't really know which is correct, is floor(-0) == 0 or -0?
For C it shouldn't really matter since 0 is the same as -0
in comparisons.
scalb(-1, -2100) returns 0 instead of -0. 2 ** -2100 is
effectively 0 but -anything * 0 == -0 according to the 68881.
Similarly for scalb(-pi, 2100). It returns INF instead
of -INF. 2 ** 2100 is effectively INF but -anything * INF
is -INF. What is correct?
drem(+-1, +-2) fails as mentioned above. This is a real error.
----
Mike Hibler
U of Utah CS Dept.
mike@cs.utah.edu
d441c2db7e