Re: compilation problem with module function interface definition
James Giles wrote:
(snip regarding float decimal)
Well, sort of. The IEEE proposed decimal float will store seven
digits. While comparing precision of representations with different
bases is difficult, one measure is the relative spacing between
representable values. In the 7 digit decimal, the relative spacing
varies from one part in ten to the seventh all the way to one part
in ten to the sixth. Meanwhile, with the 24-bit binary representation,
the relative spacing varies between one part in two to the twenty-
fourth and one part in two to the twenty-third - that's almost
twice as good as the finest end of the seven digit decimal for
some values and only a little worse than the finest end of the
seven digit decimal at worst. So, the binary is, on average,
better precision.
There is always a trade off between fraction bits and exponent
bits, though it isn't so easy to see in the decimal case.
7 decimal digits in 24 bits allows 7 bits for the exponent,
allowing one exponent value for other uses, between 10**-63
and 10**63. A binary representation with the same range would
require nine exponent bits, so one fewer fraction bits than
described above.
One rarely has the ability to trade exponent bits for fraction
bits, VAX D and G float being the only one I can remember,
but in overall bit efficiency they are fairly equal.
(That is, considering both exponent and fraction bits.)
(Also, for some calculations it is the average number of bits
of significance that are important, for others it is the minimum.)
> But, even more to the point, even if the decimal
> were slightly better on average, the wide variation makes it less
> appealing numerically.
That is the reason that IBM's hex float was not liked much.
Assume, though, that the results will be printed decimal,
the precision variation (relative spacing) is always there.
It does complicate some algorithms slightly, though.
In discussions of significant figures, it is rarely indicated
that 1.00 has only two sig. figs, where 9.99 has (almost) three.
> Mixed mode between binary and decimal
> of approximately the same precisions should probably result in
> binary for best results.
Yesterday I was thinking mixed mode meant between fixed binary
and float decimal....
Unfortunately, Fortran makes the reverse decision. I looked it
up and the standard specifies that mixed-KIND expressions will
result in the KIND that carries the most precision as defined by
the PRECISION intrinsic function. The precision is defined there
as INT( (p-1) + LOG10(b)) + k. Here, b is the base, p is the number
of base-b digits, and k is zero unless b is a multiple of 10, in which
case k is one. This use of k has the effect of comparing the relative
spacing of non-decimal KINDs at the worst part of their range to
the relative spacing of decimal KINDs at the best part of their range.
And the fact that the result is truncated to an INT further penalizes
non-decimal KINDs. By this formula, 24-bit binary has a precision
of 6 while 7 digit decimal has (obviously) a precision of 7. But,
comparing apples to apples, the widest relative spacing of the
binary carries about 6.92 decimal-equivalent digits and the widest
relative spacing of the decimal carries only 6.
But consider that you might want to print out the number.
With seven decimal digits you can print out all seven with the
relative spacing one in the last digit. Now consider printing
the binary number in decimal. The unfair spacing is always
there for decimal formatted output. (Though with the traditional
format with a leading zero (without a P descriptor) it is even
one digit worse.)
-- glen
.
