On Wed, Apr 27, 2011 at 07:09, Jerry DeLisle <jvdeli...@frontier.com> wrote:
> On 04/25/2011 07:36 AM, Janne Blomqvist wrote:
>>
>> On Mon, Apr 25, 2011 at 14:44, Jerry DeLisle<jvdeli...@frontier.com>
>> wrote:
>>>
>>> On 04/25/2011 03:48 AM, Janne Blomqvist wrote:
>>>>
>>>> Now, for one of the testcase changes:
>>>>
>>>> --- gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (revision 172909)
>>>> +++ gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (working copy)
>>>> @@ -24,11 +24,11 @@ program char4_iunit_1
>>>> write(string, *) .true., .false. , .true.
>>>> if (string .ne. 4_" T F T ") call
>>>> abort
>>>> write(string, *) 1.2345e-06, 4.2846e+10_8
>>>> - if (string .ne. 4_" 1.23450002E-06 42846000000.000000 ") call
>>>> abort
>>>> + if (string .ne. 4_" 1.234500019E-06 42846000000.000000 ") call
>>>> abort
>>>>
>>>> This looks wrong. For correctly rounded REAL(4) output, we need 9
>>>> significant digits, but here we print 10.
>>>>
>>>
>>> Well, I bumped it up for defaults based on pr48488 comment #2 shown
>>> below.
>>
>> Yes, that comment in the PR is correct; to guarantee that a
>> binary->ascii->binary roundtrip preserves the original binary value
>> (with the default "round to nearest, break on even" rounding mode),
>> one must output at least {9, 17, 21, 36} significant digits for real
>> kinds 4, 8, 10, and 16, respectively (yes, I double-checked IEEE
>> 754-2008 that this is indeed correct).
>>
>> Since for the G edit descriptor d is equivalent to the number of
>> significant digits, AFAICS the write.c patch below is correct and the
>> bug must be elsewhere, no?
>>
>
> No.
>
> Look at this example:
>
> program t4
> implicit none
> character(len=44) :: string
> write(*,*) 1.2345e-06, 4.2846e+10_8
> write(*,'(1x,1pG16.9e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
> write(*,'(1x,1pG15.8e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
> end program t4
>
> This gives with the patch:
>
> 1.234500019E-06 42846000000.000000
> 1.234500019E-06 42846000000.000000
> 1.23450002E-06 42846000000.000000
>
> And without the patch:
>
> 1.23450002E-06 42846000000.000000
> 1.234500019E-06 42846000000.000000
> 1.23450002E-06 42846000000.000000
>
> d is the number of digits after the decimal point, not the number of
> significant digits.
I stand corrected. Or well, I still stand by my previous statement
that with the G edit descriptor d corresponds to the number of
significant digits. However, only when not using the scale factor.
Since we use a scale factor of 1, when the magnitude of the number is
such that the E edit descriptor is used, according to F2008 10.7.2.3.3
paragraph 6 for 0 < k < d+2 we must print k significant digits to the
left of the decimal point and d-k+1 to the right. That is, with k=1 we
print one digit to the left of the decimal point and d-1+1=d to the
right which has the effect of increasing the number of significant
digits by one!
However, when the magnitude of the value is such that F editing is
used, the scale factor has no effect and we thus print d significant
digits.
So in order to guarantee an exact binary<->ascii roundtrip we must
accept an extra digit in some cases. Or then do something which would
make list formatted (and perhaps G0 as well?) write differ from 1PGw.d
(effectively, reduce d by one when the magnitude is such that E
editing is used)?
--
Janne Blomqvist
