On Tue, Jun 14, 2011 at 06:51, jerry DeLisle wrote:
>> It should be easy to implement:
>>
>> After the switch between F and E editing, we just need to shift the
>> decimal point and decrement the exponent. No new rounding is required,
>> because we keep the number of significant digits.
>>
>
> OK,
On 06/11/2011 12:23 AM, Thomas Henlich wrote:
I don't agree with this; with the patch we now output 10 significant
digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip.
So please retain the "reduce d by one when E editing is used" thing
for list format and G0. This is just a side
On Sat, Jun 11, 2011 at 8:56 AM, Thomas Henlich wrote:
On Sat, Jun 11, 2011 at 14:41, jerry DeLisle
wrote:
This was established as solution to PR48488 where we had two choices
for
selecting the significant digits. Nine significant digits was
established as
a requirement to guarantee round tri
On Sat, Jun 11, 2011 at 14:41, jerry DeLisle wrote:
> This was established as solution to PR48488 where we had two choices for
> selecting the significant digits. Nine significant digits was established as
> a requirement to guarantee round trip in all cases. The char4_iunit_1.f03
> test case was
On 06/11/2011 12:23 AM, Thomas Henlich wrote:
I don't agree with this; with the patch we now output 10 significant
digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip.
So please retain the "reduce d by one when E editing is used" thing
for list format and G0. This is just a side
> I don't agree with this; with the patch we now output 10 significant
> digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip.
> So please retain the "reduce d by one when E editing is used" thing
> for list format and G0. This is just a side effect of using 1PGw.d
> format for lis
On Fri, Jun 10, 2011 at 20:27, jerry DeLisle wrote:
> On 06/03/2011 05:51 AM, jerry DeLisle wrote:
>>
>> Hi,
>>
>> The attached patch, which includes test cases, fixes this bug by
>> eliminating the
>> code which used floating point instructions to determine the 'r' value as
>> outlined in the For
On 06/03/2011 05:51 AM, jerry DeLisle wrote:
Hi,
The attached patch, which includes test cases, fixes this bug by eliminating the
code which used floating point instructions to determine the 'r' value as
outlined in the Fortran standard under G formatting.
Essentially, the code now examines the
