.... produces distinct results from nearly each compiler that I tried:

0.17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836800000000000+309

***************************************************************************************************************************************************************************************************************************************************************

0.17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836800000000000+309

0.17976931348623157081452742373170435679807000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000+309

0.17976931348623157081452742373200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000+309

I think that the first and third outputs are correct. Can the others be said to conform?

On 3/20/2023 12:07 PM, Peter Klausler US wrote:
> ... produces distinct results from nearly each compiler that I tried:
>
> 0.17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836800000000000+309
>
> ***************************************************************************************************************************************************************************************************************************************************************
>
> 0.17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836800000000000+309
>
> 0.17976931348623157081452742373170435679807000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000+309
>
> 0.17976931348623157081452742373200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000+309
>
> I think that the first and third outputs are correct. Can the others be said to conform?

All of them conform. For the second, the values of 330 and 320 for w and
d exceed the compiler's limits. I assume this was Intel you tried, and
it produces the following warnings:
t.f90(1): warning #7557: Edit descriptor fields d and e must be less
than or equal to 255 - using 255.
print '(E330.320)', huge(1.d0)
---------^
t.f90(1): warning #7557: Edit descriptor fields d and e must be less
than or equal to 255 - using 255.
print '(E330.320)', huge(1.d0)
-------------^
t.f90(1): remark #8291: Recommended relationship between field width 'W'
and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
print '(E330.320)', huge(1.d0)

As for the others, I'd argue that all of these strings correspond to the
internal value. In general, all you need is three additional decimal
digits over the decimal precision of the kind to exactly specify a
particular internal value.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Monday, March 20, 2023 at 10:55:47 AM UTC-7, Steve Lionel wrote:
> As for the others, I'd argue that all of these strings correspond to the
> internal value. In general, all you need is three additional decimal
> digits over the decimal precision of the kind to exactly specify a
> particular internal value.

I see that 13.7.2.3.3p4 defines "x1 x2 . . . xd are the d most significant digits of the internal value after rounding" and 13.7.2.3.8 describes the rounding process as a choice of representable values (decimal in the case of (non-EX) output). Any floating-point value that is an integer is exactly representable in decimal, given sufficient digits. But I can't find any text that permits an exact representable decimal result to be rounded to a number of decimal digits fewer that 'd'.

On 3/20/2023 2:40 PM, Peter Klausler US wrote:
> I see that 13.7.2.3.3p4 defines "x1 x2 . . . xd are the d most significant digits of the internal value after rounding" and 13.7.2.3.8 describes the rounding process as a choice of representable values (decimal in the case of (non-EX) output). Any floating-point value that is an integer is exactly representable in decimal, given sufficient digits. But I can't find any text that permits an exact representable decimal result to be rounded to a number of decimal digits fewer that 'd'.

Consider (ignore the line wrapping):

program test
implicit none
character(80) :: string
real(kind(0.D0)) :: x

string =
'0.179769313486231570814527423731704356798070567525844996598917476803157E+309'
read (string,'(E80.73)') x
write (*,'(Z16.16)') x

string =
'0.179769313486231570814527423731704356798070000000000000000000000000000E+309'
read (string,'(E80.73)') x
write (*,'(Z16.16)') x

string =
'0.179769313486231570814527423732000000000000000000000000000000000000000E+309'
read (string,'(E80.73)') x
write (*,'(Z16.16)') x

end

(This program isn't strict F2018, but the use of Z format for
non-integers is widely accepted.) When I build and run this I get:

7FEFFFFFFFFFFFFF
7FEFFFFFFFFFFFFF
7FEFFFFFFFFFFFFF

Who's to say one string is "more correct" than the other? Why do you
assume that huge(1.0d0) is exactly representable in decimal?

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

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.

On Monday, March 20, 2023 at 1:51:00 PM UTC-7, 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.

You mean if you assume all the bits to the right of the LSB are zero?

Reminds me that the C printf routine for %f format expands the width
give to fit the value. Some machines have a floating point format with
very large maximum value.

As for the bits to the right, the IBM 7030 has a switch on the panel to
select filling with 0's or 1's on post normalization.

The idea is to run the program both ways, and look for differences.

On Monday, March 20, 2023 at 2:32:17 PM UTC-7, gah4 wrote:
> You mean if you assume all the bits to the right of the LSB are zero?

By "finite number" I meant the values aren't IEEE-754-ish infinities or NaNs. I did assume finite precision, though, and should have been explicit about that.

(But I think that the claim is true when there's a contiguous *infinite* sequence of one bits below the LSB, too.

Let x.= 0.11111111... in binary. Then 2x = 1.11111111..., so 2x-x = 1.0, so x+x-x = 1.0, so x = 1.0.)

On Monday, March 20, 2023 at 3:12:36 PM UTC-7, Peter Klausler US wrote:
> On Monday, March 20, 2023 at 2:32:17 PM UTC-7, gah4 wrote:
> > You mean if you assume all the bits to the right of the LSB are zero?

> By "finite number" I meant the values aren't IEEE-754-ish infinities or NaNs.
> I did assume finite precision, though, and should have been explicit about that.
> (But I think that the claim is true when there's a contiguous *infinite* sequence of one bits below the LSB, too.
> Let x.= 0.11111111... in binary. Then 2x = 1.11111111..., so 2x-x = 1.0, so x+x-x = 1.0, so x = 1.0.)

Physics people are used to numbers having an uncertainty, and so floating
point is convenient. I then doesn't make sense to give any specific value
to digits past the end.

The OS/360 trigonometric routines will refuse calls with arguments
so large that there are no fraction bits.

Not so much later, I knew someone with a brand new HP-55 calculator.
If you so sin(9.999999999e99) (in degree mode) you get a non-zero value.
If you believe that is followed by zero digits, it is a multiple of 360.
Best not to do that.

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.

$.02 -Ron Shepard

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.
>
> $.02 -Ron Shepard

That's true, and it does apply to huge(1d0), but the question really applies to all non-NaN non-infinite floating-point values with a radix that is a power of two and a finite number of mantissa bits. (And the proof is trivial that any positive or negative finite power of two has a finite exact decimal representation, and any sum of finite decimals will also be finite.) So I'm still not clear how some of those outputs above can qualify as conforming decimal representations for a specific binary FP number that -- like any binary floating-point non-NaN non-infinite value -- has only one exact decimal representation (modulo leading or trailing zeroes).

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?

I was in college not long after pocket scientific calculators were affordable
for college students. We liked to write down answers to numeric problems
to 10 digits. Our TAs would write SIGFIGs over our answers, and usually
take off points.

We learned fast.

Answers have a finite, and usually small, number of significant digits.
We have no idea, and no expectation that we should have any idea,
about any following digits.

Maybe we assume that they are zeros, as it is too much work to assume
anything else.

For a fun story about what you can, and can't say, about things that
are not measured, you might read this one:

https://www.sciencenews.org/wp-content/uploads/2010/11/baseball.pdf

You might be surprised about some assumptions that aren't true.

(Most of the time we were supposed to write algebraic answers to
problems, so the actual problem of digits didn't come up all that often.)

On Wednesday, March 22, 2023 at 1:21:53 PM UTC-7, 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?
>
> I was in college not long after pocket scientific calculators were affordable
> for college students. We liked to write down answers to numeric problems
> to 10 digits. Our TAs would write SIGFIGs over our answers, and usually
> take off points.
>
> We learned fast.
>
> Answers have a finite, and usually small, number of significant digits.
> We have no idea, and no expectation that we should have any idea,
> about any following digits.
>
> Maybe we assume that they are zeros, as it is too much work to assume
> anything else.
>
> For a fun story about what you can, and can't say, about things that
> are not measured, you might read this one:
>
> https://www.sciencenews.org/wp-content/uploads/2010/11/baseball.pdf
>
> You might be surprised about some assumptions that aren't true.
>
> (Most of the time we were supposed to write algebraic answers to
> problems, so the actual problem of digits didn't come up all that often.)

I took an atomic physics class from a professor who didn't want to teach, so he
made it as easy as possible on himself. Each exam had 10 questions worth 10
points each. If you got the same answer to a question as the professor, given
to three and only three significant figures, using a slide rule, you got 10 points.
If not, you got zero points. I learned little, got a C for the class, and was just
happy to be done with it.

On Wednesday, March 22, 2023 at 2:07:56 PM UTC-7, Jeff Ryman wrote:

(snip)

> I took an atomic physics class from a professor who didn't want to teach, so he
> made it as easy as possible on himself. Each exam had 10 questions worth 10
> points each. If you got the same answer to a question as the professor, given
> to three and only three significant figures, using a slide rule, you got 10 points.
> If not, you got zero points. I learned little, got a C for the class, and was just
> happy to be done with it.

I had a thermodynamics class, where it was explained that most classes
have exams with easy and hard question, where hard questions are worth
more points. His would have easy and hard questions all worth the same
number of points.

Hard questions having more points compresses the grade scale.

I do remember, though, one question where the sort-of obvious
answer was zero, but just in case I worked on it some more.
I didn't get to finish, but the answer was zero.

Now, since you are supposed to show work, I don't know if I would
have gotten the points just for writing 0, though.

On Thursday, March 23, 2023 at 8:19:03 AM UTC+13, Peter Klausler US 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.
> >
> > $.02 -Ron Shepard
> That's true, and it does apply to huge(1d0), but the question really applies to all non-NaN non-infinite floating-point values with a radix that is a power of two and a finite number of mantissa bits. (And the proof is trivial that any positive or negative finite power of two has a finite exact decimal representation, and any sum of finite decimals will also be finite.) So I'm still not clear how some of those outputs above can qualify as conforming decimal representations for a specific binary FP number that -- like any binary floating-point non-NaN non-infinite value -- has only one exact decimal representation (modulo leading or trailing zeroes).

Even if you don't ask for vast numbers of digits, differnt compilers can give very different results with huge. I believe the program below is standard-conforming and so is what gfortran and ifort do with it. Finding the reason for the difference is an instructive lesson in floating-point arithmetic..

program bigtest
character bigch*32, errmsg*80
integer ios
real(kind(1d0)):: x = huge(x), y = huge(x)
write(bigch,*) x
write(*,*) bigch
read(bigch,*,iostat=ios,iomsg=errmsg) x
if(ios/=0) write(*,*) errmsg
write(bigch,"(ES27.19E3)") y
write(*,*) bigch
read(bigch,"(ES27.19E3)",iostat=ios,iomsg=errmsg) y
if(ios/=0) write(*,*) trim(errmsg)
end program bigtest

gfortran output:
1.7976931348623157E+308
1.7976931348623157081E+308
ifort output:

1.797693134862316E+308
input conversion error, unit -5, file Internal List-Directed Read

1.7976931348623157081E+308

On Monday, March 20, 2023 at 5:12:36 PM UTC-5, Peter Klausler US wrote:
....
> (But I think that the claim is true when there's a contiguous *infinite* sequence of one bits below the LSB, too.
>
> Let x.= 0.11111111... in binary. Then 2x = 1.11111111..., so 2x-x = 1.0, so x+x-x = 1.0, so x = 1.0.)

That does not quite work that way with a finite representation (e.g. 32-bit IEEE real).

program hello
equivalence (iu,u)
data iu/Z'3FFFFFFF'/
x = u/2 ! 0.111.... in binary
y = 2*x ! 1.111.... in binary
z = y - x ! is this exactly 1 ?
print *, x, y, z
end program