On 3/22/23 3:21 PM, gah4 wrote:
> On Wednesday, March 22, 2023 at 9:19:07 AM UTC-7, Ron Shepard wrote:
>> On 3/20/23 3:50 PM, Peter Klausler US wrote:
>>> On Monday, March 20, 2023 at 1:03:44 PM UTC-7, Steve Lionel wrote:
>>>> Why do you assume that huge(1.0d0) is exactly representable in decimal?
>
>>> Because every finite binary floating-point number has an exact decimal value.
>> Also, every floating point number larger than 1/epsilon has a
>> mathematical integer value (which of course cannot usually be
>> represented as a fortran integer). The ones with large exponents have
>> lots of trailing zeros.
>
> But why do you believe they are trailing zeros?

You are right. The trailing zeros are binary zeros in the internal
representation, not necessarily decimal zeros after the output conversion.

The discussions about significant digits only apply to this problem in a
specific way, and in fact apply to both fixed point and floating point
arithmetic. As taught in school, it is usually applied to fixed point
arithmetic done by hand. But with floating point in a computer, each
value that is represented has an exact value. The specific way that
significant digits apply is that the fortran processor converts that
exact value to a decimal representation, and that conversion need not be
exact. The rounding mode specified in the open statement determines how
the inexact situations are treated (see 13.7.2.3.8). However, most of
that discussion is related to how the internal representation is
determined from the exact value on input, not the other way around. Is
there another section in the standard that also covers this output
conversion process?

In addition to the ew.d fields that are being discussed here, output
fields like fw.d or even f0.d can produce very long output strings with
dozens or hundreds of digits.

$.02 -Ron Shepard

On Thursday, March 23, 2023 at 9:59:47 AM UTC-7, Ron Shepard wrote:

(snip)

> The discussions about significant digits only apply to this problem in a
> specific way, and in fact apply to both fixed point and floating point
> arithmetic. As taught in school, it is usually applied to fixed point
> arithmetic done by hand. But with floating point in a computer, each
> value that is represented has an exact value. The specific way that
> significant digits apply is that the fortran processor converts that
> exact value to a decimal representation, and that conversion need not be
> exact. The rounding mode specified in the open statement determines how
> the inexact situations are treated (see 13.7.2.3.8). However, most of
> that discussion is related to how the internal representation is
> determined from the exact value on input, not the other way around. Is
> there another section in the standard that also covers this output
> conversion process?
In reply to a question about Fortran expression precision, the reply
was that it was legal for all floating point expressions to have
the value 42. That would not be a high quality implementation.

Significant digits definitely applies when a calculator is used,
and should also for a computer. They are a way to show
uncertainty, when one isn't up to giving it an actual
value.

Now I can explain the actual question that got the 42 result.
In Fortran single precision multiply gives a single
precision result. IBM S/360 and S/370 multiply
instruction gives a double precision result.
(MEER was added to ESA/390 many years later.)
Compilers I know generate the extra instructions
to zero the rest of the bits. It seems that Fortran
doesn't require that, though.

The Intel 8087 most often generates full width
product in registers, but will store values as
specified. That matters when optimizers
keep values in registers. Even more, they
can store some and not others.

In any case, you are free to believe that floating
point values have an infinite number of trailing
decimal or binary zeros. You may or may not
find that in actual use.