PROGRAM FORMAT
      REAL*8   R
      R=123.4567890E-10
      WRITE(*,1) R
    1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
      END

This little test is causing different results with at least two
different compilers.
MS Fortran gives a leading negative sign, a dot and the rest of the
digits, with an updated exponent (as my MS manual defines precisely
that use of the zero scale in E formats and as shown in the output
text field)..

A CVF compiler reportedly (I'm informed, haven't run it myself) loses
the sign, and with a longer field length would give (gives) a leading
negative sign then a zero, then the decimal point and further digits.

My manual:  "For a scale factor of zero, the output field is a minus
sign (if necessary), followed by a decimal point, followed by a string
of digits, followed by an exponent field, (exp), of one of the
following forms....."

 A different interpretation of, for kPFw.d   "k significant digits, a
dot, then d-k-1 digits followed by an exponent"? Could it be some
think a leading zero left of the dot is significant

Does " k significant digits" mean none if k is zero? Or not?

"k significant digits to the left of the decimal point, and d-k-1
places after the decimal point" .

  i.e. w=k+1+d+4    for exponents needing 1 to 3 digits (Esdd or
sddd).

Terence wrote:
>       PROGRAM FORMAT
>       REAL*8   R
>       R=123.4567890E-10
>       WRITE(*,1) R
>     1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
>       END
> 
> This little test is causing different results with at least two
> different compilers.


OK, after turning it into Fortran (original does not compile because of
the full stop after the 9 in the Format statement) I get the following:

Wot now ? cat ter2.f90
PROGRAM FORMAT
   Integer, Parameter :: wp = Selected_real_kind( 12, 70 )
   REAL(wp) ::  R
   R=123.4567890E-10
   WRITE(*,1) R
1 FORMAT(' >',0PE15.9,'< EXPECT >-.123456789E-07< ')
END PROGRAM FORMAT
Wot now ? nagfor ter2.f90
NAG Fortran Compiler Release 5.2(721)
[NAG Fortran Compiler normal termination]
Wot now ? ./a.out
  >0.123456791E-07< EXPECT >-.123456789E-07<
Wot now ? gfortran -std=f95 -Wall -Wextra ter2.f90
Wot now ? ./a.out
  >0.123456791E-07< EXPECT >-.123456789E-07<
Wot now ? g95 -std=f95 -Wall -Wextra ter2.f90
Wot now ? ./a.out
  >0.123456791E-07< EXPECT >-.123456789E-07<
Wot now ? f90 ter2.f90
Wot now ? ./a.out
  >0.123456791E-07< EXPECT >-.123456789E-07<
Wot now ? ~/Download/open64-4.2.3-0/bin/openf90 ter2.f90
Wot now ? ./a.out
  >0.123456791E-07< EXPECT >-.123456789E-07<

f90 is the sun compiler

Ian

On Nov 16, 1:36=A0am, Terence <tbwri...@cantv.net> wrote:
> =A0 =A0 =A0 PROGRAM FORMAT
> =A0 =A0 =A0 REAL*8 =A0 R
> =A0 =A0 =A0 R=3D123.4567890E-10
> =A0 =A0 =A0 WRITE(*,1) R
> =A0 =A0 1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
> =A0 =A0 =A0 END

[...]
Is there a typo is assigning R?  If not, why
would you expect a leading minus sign???

    -Ken

Ken Fairfield wrote:
> On Nov 16, 1:36 am, Terence<tbwri...@cantv.net>  wrote:
>>        PROGRAM FORMAT
>>        REAL*8   R
>>        R=123.4567890E-10
>>        WRITE(*,1) R
>>      1 FORMAT('>',0PE15.9.'<  EXPECT>-.123456789E-07<  ')
>>        END
>
> [...]
> Is there a typo is assigning R?  If not, why
> would you expect a leading minus sign???
>
>      -Ken

Gosh, the minus sign might actually make a difference ?


C:\temp>type format.for
       PROGRAM FORMAT
       REAL*8   R
       R=-123.4567890E-10
       WRITE(*,1) R
     1 FORMAT(' >',0PE15.9'< EXPECT >-.123456789E-07< ')
       END


C:\temp>gfortran format.for

C:\temp>a
  >-.123456791E-07< EXPECT >-.123456789E-07<

C:\temp>

"Terence" <tbwright@cantv.net> wrote in message 
news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
>
>      PROGRAM FORMAT
>      REAL*8   R
>      R=123.4567890E-10
>      WRITE(*,1) R
>    1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
>      END
>

With CVF 6.6C, after substituting '.' for ',',  I get:

 >0.123456791E-07< EXPECT >-.123456789E-07<


With R set to a negative, I get:

 >-.123456791E-07< EXPECT >-.123456789E-07<

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing

>
> 

"Colin Watters" <boss@qomputing.com> wrote in message 
news:ibum8d$fsm$1@news.eternal-september.org...
> "Terence" <tbwright@cantv.net> wrote in message 
> news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
>>
>>      PROGRAM FORMAT
>>      REAL*8   R
>>      R=123.4567890E-10
>>      WRITE(*,1) R
>>    1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
>>      END
>>
>
> With CVF 6.6C, after substituting '.' for ',',  I get:
>
> >0.123456791E-07< EXPECT >-.123456789E-07<
>
>
> With R set to a negative, I get:
>
> >-.123456791E-07< EXPECT >-.123456789E-07<
>
 >-.123456789E-07< EXPECT >-.123456789E-07<

....And, after converting the constant to double precision:

      PROGRAM FORMAT
      REAL*8   R
      R=-123.4567890D-10
      WRITE(*,1) R
    1 FORMAT(' >',0PE15.9,'< EXPECT >-.123456789E-07< ')
      END

 >-.123456789E-07< EXPECT >-.123456789E-07<

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing 

Ken Fairfield <ken.fairfield@gmail.com> wrote:

> On Nov 16, 1:36 am, Terence <tbwri...@cantv.net> wrote:
> >       PROGRAM FORMAT
> >       REAL*8   R
> >       R=123.4567890E-10
> >       WRITE(*,1) R
> >     1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
> >       END
> 
> [...]
> Is there a typo is assigning R?  If not, why
> would you expect a leading minus sign???

Yes, that would seem a rather obvious question. If a negative sign gets
lost, that clearly is a bug somewhere. The evidence presented points
pretty strongly at "somewhere" not being in the compiler. Between having
only a 3rd-hand report of the sign getting lost, plus seeing it omitted
from the posted code, I don't think we have even "probable cause" to
indict the compiler.

I won't bother to try to comment on fine points of interpretation of the
exact words of whatever it is that Terence is labelling as "my manual".
Other compilers are not required to follow whatever that might be. They
are required to follow the standard. The standard explicitly shows the
leading zero as being optional for the 0P case. The optionality is with
the compiler, so yes, different compilers can do it differently.

However, there is a relevant tidbit hiding in 10.6.1(5) of f2003. I
didn't bother to dig out the citation for f77, but I'm sure it is there
as well because I recall taking advantage of it. That tidbit is

  "However, the processor shall not produce asterisks if the field
   width is not exceeded whan optional characters are omitted."

In my own words, that means that the optional 0 is purely cosmetic; it
cannot be used as an excuse to say that the value can't fit in the field
(or that fewer significant digits should be given). I used to take
advantage of this by specifying my fields to have no room for the
optional zero, thus forcing the processor to omit them. Yes, by the way,
this does mean that you can sometimes have the same format produce a
zero for positive values, but not negative ones.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 16/11/2010 19:32, Colin Watters wrote:
> "Terence"<tbwright@cantv.net>  wrote in message
> news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
>>
>>       PROGRAM FORMAT
>>       REAL*8   R
>>       R=123.4567890E-10
>>       WRITE(*,1) R
>>     1 FORMAT('>',0PE15.9.'<  EXPECT>-.123456789E-07<  ')
>>       END
>>
>
> With CVF 6.6C, after substituting '.' for ',',  I get:
>
>   >0.123456791E-07<  EXPECT>-.123456789E-07<
>
>
> With R set to a negative, I get:
>
>   >-.123456791E-07<  EXPECT>-.123456789E-07<
>
Your assignment assigns a real*4 value to a real*8 variable. Therefor 
the result you got is probably valid since it has 7 digits correct which 
is about right for a real*4. Maybe you are using a compiler switch to 
promote constants to real*8?

or try R=123.4567890D-10

Andrew Smith <bigtits@ntlworld.com> wrote:

> Maybe you are using a compiler switch to 
> promote constants to real*8?

Or using a compiler that does this even without a special switch. Some
do so, depending on context. Some compiler vendors have considered that
a "helpful" feature. I personally consider it more of a hindrance than a
help in that it papers over the problem, hiding it for now and probably
making it harder to find in the future. It also establishes unrealistic
expectations that will also cause future problems.

I could understand the merits of a warning message (preferably a "smart"
one that only triggerred in the case of actual precision loss and didn't
bitch every time I wote something like double_variable=1.0, which is
"safe" in practice). But I don't like it when compilers quietly do what
they think I meant, even though it isn't what I said, and don't bother
to tell me about their reinterpretation.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Nov 16, 9:05=A0pm, Ian Bush <please@dont_email_me.at.all> wrote:
  etc, correctly spotting two typos (why I don't know).
One was the sign of R was missing and supposed to be negative and was
in testing; a dot after the 15.9 is my copying error and should have
been a comma.

  After correction and running Ian reported:-
> =A0 >0.123456791E-07< EXPECT >-.123456789E-07<
> f90 is the sun compiler
> Ian

Which is great, becaue both compiler ataully got that.

For the record this is the corrected test (corrected).
>       PROGRAM FORMAT
>       REAL*8   R
>       R=3D-123.4567890E-10
>       WRITE(*,1) R
>     1 FORMAT(' >',0PE15.9,'< EXPECT >-.123456789E-07< ')
>       END

However a new test has become necessary because the problem two of us
are having seems to be related to this coding of a generated F
format:-

       PROGRAM E3
       IMPLICIT NONE
       REAL*8       V
       V =3D -0.116510537214346D-01
       WRITE(*,1) V
     1 FORMAT(' >',F007.04,'< EXPECT > -.0117< ')
       END

Briefly, I do get one blank (when V positive) then -.0117 with my MS
compiler and another (CVF) gives -0.0117 with no leading blank.  Since
the leading zero is not expected by the code, that negative sign gets
lost because b-.0117 was expected. Note: a scale factor of zero is
assumed to be the default and is actually set as zero in the only
alternative use as in the first code above.

On Nov 17, 6:26=A0am, user1 <us...@example.net> wrote:
> Ken Fairfield wrote:
> > On Nov 16, 1:36 am, Terence<tbwri...@cantv.net> =A0wrote:
> >> =A0 =A0 =A0 =A0PROGRAM FORMAT
> >> =A0 =A0 =A0 =A0REAL*8 =A0 R
> >> =A0 =A0 =A0 =A0R=3D-123.4567890E-10
> >> =A0 =A0 =A0 =A0WRITE(*,1) R
> >> =A0 =A0 =A01 FORMAT('>',0PE15.9'< =A0EXPECT>-.123456789E-07< =A0')
> >> =A0 =A0 =A0 =A0END
>
> > [...]
> > Is there a typo is assigning R? =A0If not, why
> > would you expect a leading minus sign???
>
> > =A0 =A0 =A0-Ken
>
> Gosh, the minus sign might actually make a difference ?

YES! Exactly the problem seen in CVF!

>
> C:\temp>type format.for
> =A0 =A0 =A0 =A0PROGRAM FORMAT
> =A0 =A0 =A0 =A0REAL*8 =A0 R
> =A0 =A0 =A0 =A0R=3D-123.4567890E-10
> =A0 =A0 =A0 =A0WRITE(*,1) R
> =A0 =A0 =A01 FORMAT(' >',0PE15.9'< EXPECT >-.123456789E-07< ')
> =A0 =A0 =A0 =A0END
>
> C:\temp>gfortran format.for
>
> C:\temp>a
> =A0 >-.123456791E-07< EXPECT >-.123456789E-07<
>
> C:\temp>

On Nov 17, 7:48=A0am, nos...@see.signature (Richard Maine) wrote:
> Ken Fairfield <ken.fairfi...@gmail.com> wrote:
> > On Nov 16, 1:36 am, Terence <tbwri...@cantv.net> wrote:
> > > =A0 =A0 =A0 PROGRAM FORMAT
> > > =A0 =A0 =A0 REAL*8 =A0 R
> > > =A0 =A0 =A0 R=3D123.4567890E-10
> > > =A0 =A0 =A0 WRITE(*,1) R
> > > =A0 =A0 1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
> > > =A0 =A0 =A0 END
>
> > [...]
> > Is there a typo is assigning R? =A0If not, why
> > would you expect a leading minus sign???
>
> Yes, that would seem a rather obvious question. If a negative sign gets
> lost, that clearly is a bug somewhere. The evidence presented points
> pretty strongly at "somewhere" not being in the compiler. Between having
> only a 3rd-hand report of the sign getting lost, plus seeing it omitted
> from the posted code, I don't think we have even "probable cause" to
> indict the compiler.
>
> I won't bother to try to comment on fine points of interpretation of the
> exact words of whatever it is that Terence is labelling as "my manual".
> Other compilers are not required to follow whatever that might be. They
> are required to follow the standard. The standard explicitly shows the
> leading zero as being optional for the 0P case. The optionality is with
> the compiler, so yes, different compilers can do it differently.
>
> However, there is a relevant tidbit hiding in 10.6.1(5) of f2003. I
> didn't bother to dig out the citation for f77, but I'm sure it is there
> as well because I recall taking advantage of it. That tidbit is
>
> =A0 "However, the processor shall not produce asterisks if the field
> =A0 =A0width is not exceeded whan optional characters are omitted."
>
> In my own words, that means that the optional 0 is purely cosmetic; it
> cannot be used as an excuse to say that the value can't fit in the field
> (or that fewer significant digits should be given). I used to take
> advantage of this by specifying my fields to have no room for the
> optional zero, thus forcing the processor to omit them. Yes, by the way,
> this does mean that you can sometimes have the same format produce a
> zero for positive values, but not negative ones.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

Right observation but wrong assumption of the real problem (other that
I can't see the (D..d) punctiation is this tiny posting box, which is
still my error all th same - mea culpa..).

We are losing a negative sign in a small code routine; it is mnow
located in the treatment of F007.04. Does this have a default zero
scale or not? Or do new standards require 0PF007.04 as the format
needed to avoid a leading zero before the decimal point and all
significant digits?

On Nov 17, 7:58=A0am, Andrew Smith <bigt...@ntlworld.com> wrote:
> On 16/11/2010 19:32, Colin Watters wrote:
>
>
>
> > "Terence"<tbwri...@cantv.net> =A0wrote in message
> >news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
>
> >> =A0 =A0 =A0 PROGRAM FORMAT
> >> =A0 =A0 =A0 REAL*8 =A0 R
> >> =A0 =A0 =A0 R=3D123.4567890E-10
> >> =A0 =A0 =A0 WRITE(*,1) R
> >> =A0 =A0 1 FORMAT('>',0PE15.9.'< =A0EXPECT>-.123456789E-07< =A0')
> >> =A0 =A0 =A0 END
>
> > With CVF 6.6C, after substituting '.' for ',', =A0I get:
>
> > =A0 >0.123456791E-07< =A0EXPECT>-.123456789E-07<
>
> > With R set to a negative, I get:
>
> > =A0 >-.123456791E-07< =A0EXPECT>-.123456789E-07<
>
> Your assignment assigns a real*4 value to a real*8 variable. Therefor
> the result you got is probably valid since it has 7 digits correct which
> is about right for a real*4. Maybe you are using a compiler switch to
> promote constants to real*8?
>
> or try R=3D123.4567890D-10

Fair comment but not the problem. The usage actaully has passed values
defined as real*8 when set.

Terence <tbwright@cantv.net> wrote:

> We are losing a negative sign in a small code routine; it is mnow
> located in the treatment of F007.04. Does this have a default zero
> scale or not? Or do new standards require 0PF007.04 as the format
> needed to avoid a leading zero before the decimal point and all
> significant digits?

Nothing has changed in regards to P scaling in pretty much forever. In
large part P scaling is just so messed up, and any attempt to fix it
would have caused so many compatibility problems, that it was left as is
and new functionality was introduced in other ways instead of trying to
fix up P. (See, for example, the ES and EN edit descriptors).

As has always been the case, 0P is the default for everything, but it is
very easy to get confused because P scaling is "sticky"; any P scaling
from earlier in the format stays in effect until overridden. This has
confused plenty of people in the past.

And P scaling combined with F is just strange. It doesn't do what I
suspect you think it does. Mostly what it does is just make results look
like they are off by a factor of 10.

Put those two things together and you get people pulling their hair out
like a cow-orker of mine once did before he came to me for help. His
program was giving results off by a factor of 10 and he couldn't figure
out why. Turned out that the results were percetly fine, except that
they printed strangely.

With all the mess of confusion related to P and F, no way I would even
hazard a diagnosis based on a description of what someone thinks is
happening. The odds are *WAY* to high that what they think is happening
isn't accurate and that the description left out critical factors. In
particular, the sticky nature of P means that one cannot draw correct
conclusions by looking at a single edit descriptor in isolation; the
whole format matters. I'd insist on a complete running sample.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Terence wrote:
> On Nov 16, 9:05 pm, Ian Bush <please@dont_email_me.at.all> wrote:
>   etc, correctly spotting two typos (why I don't know).
> One was the sign of R was missing and supposed to be negative and was
> in testing; a dot after the 15.9 is my copying error and should have
> been a comma.
> 
>   After correction and running Ian reported:-
>>   >0.123456791E-07< EXPECT >-.123456789E-07<
>> f90 is the sun compiler
>> Ian
> 
> Which is great, becaue both compiler ataully got that.
> 
> For the record this is the corrected test (corrected).
>>       PROGRAM FORMAT
>>       REAL*8   R
>>       R=-123.4567890E-10
>>       WRITE(*,1) R
>>     1 FORMAT(' >',0PE15.9,'< EXPECT >-.123456789E-07< ')
>>       END
> 
> However a new test has become necessary because the problem two of us
> are having seems to be related to this coding of a generated F
> format:-
> 
>        PROGRAM E3
>        IMPLICIT NONE
>        REAL*8       V
>        V = -0.116510537214346D-01
>        WRITE(*,1) V
>      1 FORMAT(' >',F007.04,'< EXPECT > -.0117< ')
>        END
> 
> Briefly, I do get one blank (when V positive) then -.0117 with my MS
> compiler and another (CVF) gives -0.0117 with no leading blank.  Since
> the leading zero is not expected by the code, that negative sign gets
> lost because b-.0117 was expected. Note: a scale factor of zero is
> assumed to be the default and is actually set as zero in the only
> alternative use as in the first code above.
> 

same 5 compilers:
Wot now ? nagfor ter3.f90
NAG Fortran Compiler Release 5.2(721)
[NAG Fortran Compiler normal termination]
..Wot now ? ./a.out
  >-0.0117< EXPECT > -.0117<
Wot now ? gfortran ter3.f90
Wot now ? ./a.out
  >-0.0117< EXPECT > -.0117<
Wot now ? g95 ter3.f90
Wot now ? ./a.out
  >-0.0117< EXPECT > -.0117<
Wot now ? f90 ter3.f90
Wot now ? ./a.out
  >-0.0117< EXPECT > -.0117<
Wot now ? ~/Download/open64-4.2.3-0/bin/openf90 ter3.f90
Wot now ? ./a.out
  >-0.0117< EXPECT > -.0117<
Wot now ?

Ian

On Nov 17, 5:55=A0pm, nos...@see.signature (Richard Maine) wrote:
> Terence <tbwri...@cantv.net> wrote:
> > We are losing a negative sign in a small code routine; it is mnow
> > located in the treatment of F007.04. Does this have a default zero
> > scale or not? Or do new standards require 0PF007.04 as the format
> > needed to avoid a leading zero before the decimal point and all
> > significant digits?
>
> Nothing has changed in regards to P scaling in pretty much forever. In
> large part P scaling is just so messed up, and any attempt to fix it
> would have caused so many compatibility problems, that it was left as is
> and new functionality was introduced in other ways instead of trying to
> fix up P. (See, for example, the ES and EN edit descriptors).
>
> As has always been the case, 0P is the default for everything, but it is
> very easy to get confused because P scaling is "sticky"; any P scaling
> from earlier in the format stays in effect until overridden. This has
> confused plenty of people in the past.
>
> And P scaling combined with F is just strange. It doesn't do what I
> suspect you think it does. Mostly what it does is just make results look
> like they are off by a factor of 10.
>
> Put those two things together and you get people pulling their hair out
> like a cow-orker of mine once did before he came to me for help. His
> program was giving results off by a factor of 10 and he couldn't figure
> out why. Turned out that the results were percetly fine, except that
> they printed strangely.
>
> With all the mess of confusion related to P and F, no way I would even
> hazard a diagnosis based on a description of what someone thinks is
> happening. The odds are *WAY* to high that what they think is happening
> isn't accurate and that the description left out critical factors. In
> particular, the sticky nature of P means that one cannot draw correct
> conclusions by looking at a single edit descriptor in isolation; the
> whole format matters. I'd insist on a complete running sample.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

I agree with almost everything in this response of Richard, exeept the
first and last paragraphs!

Both compilers run the same code and get different results, due to a
problem now located in the use of the simple F format.

In our case, scaling is ALWAYS set to 0P and the E formatting result,
which is the only format using scaling, is correct under the two
compilers.

The odd thing is that with F format, and NO scaling actually
requested, for a value less than 1.0 in magnitude, and a format of
F007.04 as one of very many cases, one compiler (CVF) produces a
leading zero after the sign and before the decimal point, whereas the
other (Microsoft) produces a blank and the negative sign before the
dot, but no blank and one more digit for a positive value. Both yield
strings of the same length..

It seems to be a difference of implementation.

The solution so far has needed an internal write to a character string
followed by examining which of two cases result:for a value of
-0.116510537214346D-01
    "-0.0117"  or  " -.0117".

(or similar string pairs for matching increases in the values of w and
d in Fw.d starting at w=3D7 and d=3D4) .

  Then if the first three characters of the string are '-0.' , they
are replaced with ' -,' and then the two cases have a common result
and structure.

I was wondering if anybody has a strong expectation of what we should
get as per standards?

In article <1js2n23.1usy4qtyqjaiqN%nospam@see.signature>,
Richard Maine <nospam@see.signature> wrote:
>
>Nothing has changed in regards to P scaling in pretty much forever. In
>large part P scaling is just so messed up, and any attempt to fix it
>would have caused so many compatibility problems, that it was left as is
>and new functionality was introduced in other ways instead of trying to
>fix up P. (See, for example, the ES and EN edit descriptors).

That's essentially how I teach it :-)

>And P scaling combined with F is just strange. It doesn't do what I
>suspect you think it does. Mostly what it does is just make results look
>like they are off by a factor of 10.
>
>Put those two things together and you get people pulling their hair out
>like a cow-orker of mine once did before he came to me for help. His
>program was giving results off by a factor of 10 and he couldn't figure
>out why. Turned out that the results were percetly fine, except that
>they printed strangely.

As you know, for REAL fun, use a format with mixed P, E and F, and
use the same format for both output and input.


Regards,
Nick Maclaren.

On Nov 17, 8:38=A0pm, n...@cam.ac.uk wrote:
> In article <1js2n23.1usy4qtyqjaiqN%nos...@see.signature>,
>
> Richard Maine <nos...@see.signature> wrote:
>
> >Nothing has changed in regards to P scaling in pretty much forever. In
> >large part P scaling is just so messed up, and any attempt to fix it
> >would have caused so many compatibility problems, that it was left as is
> >and new functionality was introduced in other ways instead of trying to
> >fix up P. (See, for example, the ES and EN edit descriptors).
>
> That's essentially how I teach it :-)
>
> >And P scaling combined with F is just strange. It doesn't do what I
> >suspect you think it does. Mostly what it does is just make results look
> >like they are off by a factor of 10.
>
> >Put those two things together and you get people pulling their hair out
> >like a cow-orker of mine once did before he came to me for help. His
> >program was giving results off by a factor of 10 and he couldn't figure
> >out why. Turned out that the results were percetly fine, except that
> >they printed strangely.
>
> As you know, for REAL fun, use a format with mixed P, E and F, and
> use the same format for both output and input.
>
> Regards,
> Nick Maclaren.

I checked a DVF manual (assuming same as CVF) for the F90 definition
of output with F formats.

  The F77 standard I quoted is different from the F90 standard,
  In F90, the F format output stipulates "At least one digit to the
left of the decimal point."

So F77 complilation runs with a F90 or higher compiler will output F
formats with at least one digit before the decimal point, even if it
is zero. Earlier compilers may not, and not export an un-needed
leading zero after the sign.

This resolves the problem, so a simple check on the output to an
internal character string can reveal which case we have. This is not
needed if the format is Fw.0, but is needed for formats with non-zero
d in Fw.d.

This code seems to work:-

      SUBROUTINE CMAXD(V,IESW,IW,CIW)
      IMPLICIT INTEGER*4 (I-N)
C SUBROUTINE TO REDUCE REAL NUMBER TO MINIMUM CHARACTER PRESENTATION
C AUTHOR T.B.WRIGHT, TAU Systems
C IW IS REQUESTED FIELD WIDTH TO SHOW V AS TEXT, RETURNED IN FIELD CIW
C MAXIMUM FIELD LENGTH 19, MAXIMUM PRECISION 15
C IESW=3D0 TO ALWAYS REMOVE 'E', ELSE IESW=3D1, TO CHANGE ONLY 'E+' TO '+'
      REAL*8       V
C REQUIRED FIELD LENGTH, 'E' SWITCH
      INTEGER      IW,IESW
      CHARACTER*20 CIW
C WORK AREA, REMOTE FORMAT, TEST EXPONENT, FINAL UNREDUCED EXPONENT
      CHARACTER*22 C22
      CHARACTER*12 CFRM
      CHARACTER*4  C4
C WORK LENGTH, ABS(EXPONENT), MANTISSA LENGTH
      INTEGER      KW,K,ND
C EXPONENT VALUES: GIVEN AND MODIFIED
      INTEGER      IEA,IEF
C SWITCHES FOR NEGATIVE, ABS(FINAL EXPONENT)<10, +/E REMOVAL
      INTEGER      ISN,ISO,ISE
C CHARACTER STRING INDEXES TO 'E' '+' '0' IN EXPONENT
      INTEGER      K3,K2,K1
C IF NEGATIVE SIGN IN VALUE ISN=3D1 ELSE ZERO?
      ISN=3D0
      IF (V.LE.0.0D0) ISN=3D1
C GET SIGN AND MAGNITUDE OF EXPONENT IEA, USING WIDTH 8 STRING C22
      WRITE(C22,901,ERR=3D11) V
C USE FIELD WITH MANTISSA>=3D MAXIMUM SUPORTED FIELD LENGTH
s.vv..vv.Esdd
C WILL FAIL IF MAGNITUDE EXPONENT IS >999
  901 FORMAT(E22.15)
C HAVE s.vv..vvesdd OR s.vv..vvsddd
      IF (C22(19:19).EQ.'E') THEN
C HAVE s.vv..vvesdd
        READ(C22(19:22),902) IEA
  902 FORMAT(1X,I3)
      ELSE
C HAVE s.vv..vvsddd
        READ(C22(19:22),903) IEA
  903 FORMAT(I4)
      ENDIF
C CLEAR AREA
      C22=3D' '
C
C IF ORIGINAL EXPONENT BELOW -01 PERHAPS CAN USE E FORMAT
      IF (IEA.GE.-01) THEN
C K IS EFFECTIVE WIDTH WITHOUT - SIGN
        K=3DIW-ISN
        IF (IEA.LE.K) THEN
C
C****   F FORMAT POSSIBLE
C CAN USE Fw.d FORMAT WITH POINT AND ND DECIMALS (IEA IS +VE OR ZERO)
C NEED IW -DOT -#SIGNIFICANTS) DECIMALS
          ND=3DIW-ISN-1
          IF (IEA.GE.0) ND=3DND-IEA
          KW=3DIW
          IF (ND.LT.0) THEN
            K=3DIW+2
            WRITE(CFRM,904) K
            WRITE(C22,CFRM,ERR=3D11) V
  904 FORMAT('(F',I3.3,'.0 )   ')
          ELSE
            K=3DIW+1
            WRITE(CFRM,905) K,ND
            WRITE(C22,CFRM,ERR=3D11) V
  905 FORMAT('(F',I3.3,'.',I2.2,')   ')
C ELIMINATE NON-SIGNIFICANT ZERO WHEN DECIMALS PRESENT (-VE)
            IF (C22(1:3).EQ.'-0.') C22(1:3)=3D' -.'
          ENDIF
          GO TO 10
        ENDIF
      ENDIF
C
C**** E FORMAT NEEDED:
C EXPONENT FOR  s.ddEsee OR s.ddseee FORM IS IEA
C ORIGINAL EXPONENT IS IEA, MODIFIED EXPONENT WILL BE IEW
C     IEW=3DIEA-2+ISN-(IW-6)
      IEW=3DIEA+4+ISN-IW
C
C CAN REMOVE 'E' ? IESW=3D1 SAYS TAKE E, ELSE ONLY TAKE + FROM E+
      ISE=3DIESW
      IF (IEW.GT.0) ISE=3D1
C BUT NOT IF EXPONENT OVER TWO DIGITS
C TAKES >100 TO  >99?
      IF (IEW.GT.100)  ISE=3D0
C TAKES <-99 TO <-100?
      IF (IEW.LT.-99)  ISE=3D0
C INCLUDE AFFECTS OF ISE (EXPONENT MORE NEGATIVE IF MORE LEAD DIGITS)
      IEW=3DIEW-ISE
C DOES, OR CAN, EXPONENT CONTAIN LEADING ZERO?
      IS0=3D1
      IF (IEW.GT.10)  IS0=3D0
      IF (IEW.LE.-9)  IS0=3D0
C CAN GET MORE PRECISION IF ISE OR IS0 OR, BOTH AND DOT REMOVED
      IEW=3DIEW-IS0
      KW=3DIW+ISE+IS0+1
C GET ABSOLUTE VALUE OF IEW
      K=3DIEW
      IF (K.LT.0) K=3D-K
C  ERROR IF FINAL EXPONENT >999
      IF (K.GT.999) GO TO 11
C 100<IEA<100; WRITE SIGNED VALUE TO C4
      IF (K.GT.99) THEN
        WRITE(C4,906,ERR=3D11) IEW
  906 FORMAT(I4.3)
        IF (C4(1:1).EQ.' ') C4(1:1)=3D'+'
      ELSE
        WRITE(C4,907,ERR=3D11) IEW
  907 FORMAT('E',I3.2)
        IF (C4(2:2).EQ.' ') C4(2:2)=3D'+'
      ENDIF
C WORK WITH WANTED LENGTH PLUS UP TO 3 EXTRA
      KW=3DIW+ISE+IS0+1
C DOT AND EXPONENT TAKE 5 OF WORK LENGTH
      ND=3DKW-5-ISN
      WRITE(CFRM,908) KW,ND
  908 FORMAT('(0PE',I3.2,'.',I2.2,') ')
C
      WRITE(C22,CFRM) V
      K1=3DKW-3
      C22(K1:KW)=3DC4
C NEG. CASES ARE S.dddEs0e OR S.dddEsee OR s.dddseee...
C POS. CASES ARE .ddddEs0e OR .ddddEsee OR .ddddseee...
C OUTPUT IS 1,2 OR 3 LONGER THAN REQUESTED (FOR DOT,IS0,ISE)
      K1=3DKW-1
      IF (IS0.EQ.1) THEN
C REMOVE KNOWN 0 FROM Es0d
        C22(K1:K1)=3DC22(KW:KW)
        C22(KW:KW)=3D' '
      ENDIF
      K2=3DK1-1
C TAKE E OR ONLY TAKE +?
      IF (IESW.EQ.0) THEN
C REMOVE '+' IF EXPONENT <+100
        IF (C22(K2:K2).EQ.'+') THEN
          IF (IEW.LT.100) C22(K2:K1)=3DC22(K1:KW)
        ENDIF
      ELSE
C REMOVE 'E' IF EXPONENT <+100
        K3=3DK2-1
        IF (C22(K3:K3).EQ.'E') THEN
          IF (IEW.LT.100) C22(K3:K1)=3DC22(K2:KW)
        ENDIF
      ENDIF
C REMOVE DOT
      IF (C22(1:1).EQ.'-') C22(2:2)=3D'-'
   10 K1=3DIW+1
      CIW(1:IW)=3DC22(2:K1)
      RETURN
C NOT POSSIBLE
   11 CIW(1:IW)=3D'********************'
      RETURN
      END

Terence <tbwright@cantv.net> wrote:

>   The F77 standard I quoted is different from the F90 standard,
>   In F90, the F format output stipulates "At least one digit to the
> left of the decimal point."
> 
> So F77 complilation runs with a F90 or higher compiler will output F
> formats with at least one digit before the decimal point, even if it
> is zero. Earlier compilers may not, and not export an un-needed
> leading zero after the sign.

I think you are continuing a long tradition of confusing compiler
documentation with language standards. Although you specifically refer
to "the F90 standard" above in a way that implies the quotation was
taken from the standard, I can find no such words or anthing equivalent
in the actual f90 standard (or any later version, but I checked f90 very
particularly, as that's what you mentioned.) What I do find in f90 is
(in 10.5.1.2.1 F Editing)

  "Leading zeros are not permitted except for an *OPTIONAL* zero
   immediately to the left of the decimal point if the magnitude of the
   value in the output field is less than one. The optional zero must
   appear if there would otherwise be no digits in the output field."

Note the word "optional". The caps and asterisks were my additions for
emphasis. It would be quite strange if the zero were specified as
optional in that sentence but was specified elsewhere to be required. If
you can actually find such a citation in the f90 standard I would be
intrigued. The standard - not some vendor documentation.

I also checked the f77 standard - again the actual standard rather than
some vendor documentation. The exact same words are there. I suppose my
eyes might have missed something in comparing them, as I did just do it
visually, but if there was a difference, I failed to see it.

So no, none of this has anything to do with whether the compilation
"runs with a F90 or higher compiler." It might have to do with what
particular compiler it runs on, but not with whether it is an f90 or f77
compiler.

Just because a particular compiler does something and the compiler in
question is an f90 compiler, that does not mean that f90 specifies it
must be that way.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Nov 18, 11:05=A0am, nos...@see.signature (Richard Maine) wrote:
> Terence <tbwri...@cantv.net> wrote:
> > =A0 The F77 standard I quoted is different from the F90 standard,
> > =A0 In F90, the F format output stipulates "At least one digit to the
> > left of the decimal point."
>
> > So F77 complilation runs with a F90 or higher compiler will output F
> > formats with at least one digit before the decimal point, even if it
> > is zero. Earlier compilers may not, and not export an un-needed
> > leading zero after the sign.
>
> I think you are continuing a long tradition of confusing compiler
> documentation with language standards. Although you specifically refer
> to "the F90 standard" above in a way that implies the quotation was
> taken from the standard, I can find no such words or anthing equivalent
> in the actual f90 standard (or any later version, but I checked f90 very
> particularly, as that's what you mentioned.) What I do find in f90 is
> (in 10.5.1.2.1 F Editing)
>
> =A0 "Leading zeros are not permitted except for an *OPTIONAL* zero
> =A0 =A0immediately to the left of the decimal point if the magnitude of t=
he
> =A0 =A0value in the output field is less than one. The optional zero must
> =A0 =A0appear if there would otherwise be no digits in the output field."
>
> Note the word "optional". The caps and asterisks were my additions for
> emphasis. It would be quite strange if the zero were specified as
> optional in that sentence but was specified elsewhere to be required. If
> you can actually find such a citation in the f90 standard I would be
> intrigued. The standard - not some vendor documentation.
>
> I also checked the f77 standard - again the actual standard rather than
> some vendor documentation. The exact same words are there. I suppose my
> eyes might have missed something in comparing them, as I did just do it
> visually, but if there was a difference, I failed to see it.
>
> So no, none of this has anything to do with whether the compilation
> "runs with a F90 or higher compiler." It might have to do with what
> particular compiler it runs on, but not with whether it is an f90 or f77
> compiler.
>
> Just because a particular compiler does something and the compiler in
> question is an f90 compiler, that does not mean that f90 specifies it
> must be that way.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

No, I don't have a committee standard manual for F90. I was perhaps
incorrectly using well-known commercial (compilers of Fortran) manual
definitions as if they were following the standard for the basic
usages at least. Given that IBM invented Fortran (John Bachus, et al),
I treat my IBM manuals as accurate. More recently (1980's or so) I
continuned to follow the later 'carriers of the baton' of standard
Fortran.

My quote was typed directly from the chapter 11 psge 17 of the very
thick Compaq manual for F90/95 compilations (1999 update of 1994; mine
is for V6.6c). The quote by Richard closely matches the same manual's
specification for the E and D formats (page 11-12), (but NOT the F
format) where, for E and D only, is where I see the word 'optional' as
Richard states (but no indication of how to opt for it for those
Formats either).

The code I posted should have had an explanation that this was
continuing the diversion that developed from the original posting on
conversions to/from PL/1, but was the cause of the discussion on the
detected different treatment for F formats when the value output is
less than 1.0 . This is why I opend the new post relating to E and F
outputs.

At one time Compaq's Fortran, like Lahey's and Absoft's, was one of
the very popular and well-supported commercial Fortran compilers. I
believe Intel has since taken over Compaq's Fortraa (via DEC I think)
with some of te same staff.

Terence <tbwright@cantv.net> wrote:

> On Nov 18, 11:05 am, nos...@see.signature (Richard Maine) wrote:

> > Just because a particular compiler does something and the compiler in
> > question is an f90 compiler, that does not mean that f90 specifies it
> > must be that way.
...
> No, I don't have a committee standard manual for F90. I was perhaps
> incorrectly using well-known commercial (compilers of Fortran) manual
> definitions as if they were following the standard for the basic
> usages at least.

The compilers in question *DO* follow the standard. That is, however,
irrelevant. The standard allows the described behavior. The word
"optional" that I carefully pointed out was in a context that gave the
option to the compiler.

I repeat my words quoted above for emphasis because they are precisely
to the point.

> > Just because a particular compiler does something and the compiler in
> > question is an f90 compiler, that does not mean that f90 specifies it
> > must be that way.

Perhaps I should also add that just because a particular compiler does
something that the standard does not require, that does not mean there
is anything nonconforming or otherwise lacking about the compiler.

In fact, in this case, the compiler *MUST* choose an option that is not
required by the standard. The standard itself says so. In saying that
the zero is optional, the compiler does not require the omission of the
zero. Nor does it require the presense of the zero. The compiler has to
choose one of thse options, yet neither particular one is required by
the standard. I might appear to be over-belaboring the obvious
definition of what the word "optional" means, but it appears that the
elaboration is needed.

There is no error or shortcomming in the compiler for making one of the
choices. The only error is in generalizing that just because one
compiler makes a choice, that means that the standard mandates that
choice.

There actually is a reason why some of us spent years of our lives
working on standards. They are useful for some things. In particular,
they are useful for determining what things just happen to be the case
for some paricular compiler versus what things you can count on for all
conformant compilers.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Terence <tbwright@cantv.net> wrote:
(snip)

> No, I don't have a committee standard manual for F90. I was perhaps
> incorrectly using well-known commercial (compilers of Fortran) manual
> definitions as if they were following the standard for the basic
> usages at least. Given that IBM invented Fortran (John Bachus, et al),
> I treat my IBM manuals as accurate. More recently (1980's or so) I
> continuned to follow the later 'carriers of the baton' of standard
> Fortran.

IBM in the past was pretty good about marking the sections of
their manuals that were extensions to the standard.  For the S/360
and S/370 manuals, the changes in a new edition were often corrections
to the shading.  (Which means it was previously wrong.)

Some DEC manuals use a different color ink, which doesn't always
survive scanning.  (The IBM shading doesn't always do so well
for scanning, either.)  

Some others completely ignore the difference between standard
and extension.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> IBM in the past was pretty good about marking the sections of
> their manuals that were extensions to the standard. 

As noted in my other post, the question at hand is *NOT* an extension.
It is a choice between the two options allowed by the standard, namely
whether the zero is "to be or not to be". That does not count as an
extension.

I don't recall whether the manuals were also good about detailing the
implementation choices on things that the standard specified to be
implementation dependent. It would certainly be possible for them to do
that, but if you are looking for markings that indicate extensions,
you'd be looking for the wrong thing.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:
....
> I don't recall whether the manuals were also good about detailing the
> implementation choices on things that the standard specified to be
> implementation dependent. It would certainly be possible for them to do
> that, but if you are looking for markings that indicate extensions,
> you'd be looking for the wrong thing.

I don't recall anything at all about IBM manuals; I used an IBM 
virtually none.

The DEC/CVF manuals make no distinction at all for the choice of such 
optional features so there's no indication that a choice was taken what 
more what the set of choice(s) might have been.  I would presume (but 
I've not looked) that the Intel manuals are similar in formatting /content.

--

"Terence" <tbwright@cantv.net> wrote in message news:77f33149-bd6f-4885-aabb-ab0cc122a982@j9g2000vbl.googlegroups.com...
>On Nov 17, 7:58 am, Andrew Smith <bigt...@ntlworld.com> wrote:
>> On 16/11/2010 19:32, Colin Watters wrote:
>> > "Terence"<tbwri...@cantv.net> wrote in message
>> >news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
>
>> >> PROGRAM FORMAT
>> >> REAL*8 R
>> >> R=123.4567890E-10
>> >> WRITE(*,1) R
>> >> 1 FORMAT('>',0PE15.9.'< EXPECT>-.123456789E-07< ')
>> >> END
>
>> > With CVF 6.6C, after substituting '.' for ',', I get:
>
>> > >0.123456791E-07< EXPECT>-.123456789E-07<
>
>> > With R set to a negative, I get:
>
>> > >-.123456791E-07< EXPECT>-.123456789E-07<
>
>> Your assignment assigns a real*4 value to a real*8 variable. Therefor
>> the result you got is probably valid since it has 7 digits correct which
>> is about right for a real*4. Maybe you are using a compiler switch to
>> promote constants to real*8?
>
>> or try R=123.4567890D-10

>Fair comment but not the problem. The usage actaully has passed values
>defined as real*8 when set.

That's not how such constants are treated.
The constant
 123.4567890E-10
is actually treated as a SINGLE precision constant,
and consequently only about 7 digits are stored.
To get DOUBLE precision accuracy, the 'E' must be changed to 'D'. 

"Terence" <tbwright@cantv.net> wrote in message news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
|
|      PROGRAM FORMAT
|      REAL*8   R

REAL*8 isn't portable.

|      R=123.4567890E-10
|      WRITE(*,1) R
|    1 FORMAT(' >',0PE15.9.'< EXPECT >-.123456789E-07< ')
|      END
|
| This little test is causing different results with at least two
| different compilers.
| MS Fortran gives a leading negative sign, a dot and the rest of the
| digits, with an updated exponent (as my MS manual defines precisely
| that use of the zero scale in E formats and as shown in the output
| text field)..
|
| A CVF compiler reportedly (I'm informed, haven't run it myself) loses
| the sign, and with a longer field length would give (gives) a leading
| negative sign then a zero, then the decimal point and further digits.
|
| My manual:  "For a scale factor of zero, the output field is a minus
| sign (if necessary), followed by a decimal point, followed by a string
| of digits, followed by an exponent field, (exp), of one of the
| following forms....."
|
| A different interpretation of, for kPFw.d   "k significant digits, a
| dot, then d-k-1 digits followed by an exponent"? Could it be some
| think a leading zero left of the dot is significant
|
| Does " k significant digits" mean none if k is zero? Or not?
|
| "k significant digits to the left of the decimal point, and d-k-1
| places after the decimal point" .
|
|  i.e. w=k+1+d+4    for exponents needing 1 to 3 digits (Esdd or
| sddd).

   REAL X
   X = 0.0123
   WRITE (*, '(0PE10.4)' ) X
   WRITE (*, '(1PE10.4)' ) X
   WRITE (*, '(2PE10.4)' ) X
   WRITE (*, '(3PE10.4)' ) X
END

produces:

0.1230E-01
1.2300E-02
12.300E-03
123.00E-04 

Richard Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
 
>> IBM in the past was pretty good about marking the sections of
>> their manuals that were extensions to the standard. 
 
> As noted in my other post, the question at hand is *NOT* an extension.
> It is a choice between the two options allowed by the standard, namely
> whether the zero is "to be or not to be". That does not count as an
> extension.

Yes, that was in reply to Terrence not having a copy of the
standard, but using the manual for a specific system.
 
> I don't recall whether the manuals were also good about detailing the
> implementation choices on things that the standard specified to be
> implementation dependent. It would certainly be possible for them to do
> that, but if you are looking for markings that indicate extensions,
> you'd be looking for the wrong thing.

The old IBM way was to have two manuals, the first was the
"Language Reference" (which included extensions, suitably marked).

The second was the "Programmer's Guide" which contained everything 
else, including implementation decisions such as this, if one 
had thought to include them.  It usually had the calling sequence,
needed to write assembly programs callable from the compiler,
specifics about I/O (DDNAMEs, DCB paramters, and other JCL specific
things.  Also, the JCL needed to run the compiler, how much memory
it would require, temporary disk files needed, etc.

One of the strange things to appear for the Fortran H compiler,
which uses six balanced trees instead of a hash table,
is that for faster compiling one should even distribute variable
names between one and six characters.  (No suggestion about
how that might affect readability.)  Others had to do with the
way the optimizer worked, and problems that it might cause by
moving things out of loops.

Even though compilers are much bigger and more complicated now,
we get much less information about them.  

-- glen
 

On 11/18/10 5:04 PM, robin wrote:
> "Terence"<tbwright@cantv.net>  wrote in message news:1bd3cbfd-6eec-4e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
> |
> |      PROGRAM FORMAT
> |      REAL*8   R
>
> REAL*8 isn't portable.
>
> |      R=123.4567890E-10
> |      WRITE(*,1) R
> |    1 FORMAT('>',0PE15.9.'<  EXPECT>-.123456789E-07<  ')
> |      END
> |
> | This little test is causing different results with at least two
> | different compilers.
> | MS Fortran gives a leading negative sign, a dot and the rest of the
> | digits, with an updated exponent (as my MS manual defines precisely
> | that use of the zero scale in E formats and as shown in the output
> | text field)..
> |
> | A CVF compiler reportedly (I'm informed, haven't run it myself) loses
> | the sign, and with a longer field length would give (gives) a leading
> | negative sign then a zero, then the decimal point and further digits.
> |
> | My manual:  "For a scale factor of zero, the output field is a minus
> | sign (if necessary), followed by a decimal point, followed by a string
> | of digits, followed by an exponent field, (exp), of one of the
> | following forms....."
> |
> | A different interpretation of, for kPFw.d   "k significant digits, a
> | dot, then d-k-1 digits followed by an exponent"? Could it be some
> | think a leading zero left of the dot is significant
> |
> | Does " k significant digits" mean none if k is zero? Or not?
> |
> | "k significant digits to the left of the decimal point, and d-k-1
> | places after the decimal point" .
> |
> |  i.e. w=k+1+d+4    for exponents needing 1 to 3 digits (Esdd or
> | sddd).
>
>     REAL X
>     X = 0.0123
>     WRITE (*, '(0PE10.4)' ) X
>     WRITE (*, '(1PE10.4)' ) X
>     WRITE (*, '(2PE10.4)' ) X
>     WRITE (*, '(3PE10.4)' ) X
> END
>
> produces:
>
> 0.1230E-01
> 1.2300E-02
> 12.300E-03
> 123.00E-04
>
>
At the end, the talk was about kpFw.d.  What is the result if you use F 
instead of E in the formats?

Dick Hendrickson

On Nov 19, 10:40=A0am, Dick Hendrickson <dick.hendrick...@att.net>
wrote:
> On 11/18/10 5:04 PM, robin wrote:
>
>
>
> > "Terence"<tbwri...@cantv.net> =A0wrote in messagenews:1bd3cbfd-6eec-4e5=
1-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
> > |
> > | =A0 =A0 =A0PROGRAM FORMAT
> > | =A0 =A0 =A0REAL*8 =A0 R
>
> > REAL*8 isn't portable.
>
> > | =A0 =A0 =A0R=3D123.4567890E-10
> > | =A0 =A0 =A0WRITE(*,1) R
> > | =A0 =A01 FORMAT('>',0PE15.9.'< =A0EXPECT>-.123456789E-07< =A0')
> > | =A0 =A0 =A0END
> > |
> > | This little test is causing different results with at least two
> > | different compilers.
> > | MS Fortran gives a leading negative sign, a dot and the rest of the
> > | digits, with an updated exponent (as my MS manual defines precisely
> > | that use of the zero scale in E formats and as shown in the output
> > | text field)..
> > |
> > | A CVF compiler reportedly (I'm informed, haven't run it myself) loses
> > | the sign, and with a longer field length would give (gives) a leading
> > | negative sign then a zero, then the decimal point and further digits.
> > |
> > | My manual: =A0"For a scale factor of zero, the output field is a minu=
s
> > | sign (if necessary), followed by a decimal point, followed by a strin=
g
> > | of digits, followed by an exponent field, (exp), of one of the
> > | following forms....."
> > |
> > | A different interpretation of, for kPFw.d =A0 "k significant digits, =
a
> > | dot, then d-k-1 digits followed by an exponent"? Could it be some
> > | think a leading zero left of the dot is significant
> > |
> > | Does " k significant digits" mean none if k is zero? Or not?
> > |
> > | "k significant digits to the left of the decimal point, and d-k-1
> > | places after the decimal point" .
> > |
> > | =A0i.e. w=3Dk+1+d+4 =A0 =A0for exponents needing 1 to 3 digits (Esdd =
or
> > | sddd).
>
> > =A0 =A0 REAL X
> > =A0 =A0 X =3D 0.0123
> > =A0 =A0 WRITE (*, '(0PE10.4)' ) X
> > =A0 =A0 WRITE (*, '(1PE10.4)' ) X
> > =A0 =A0 WRITE (*, '(2PE10.4)' ) X
> > =A0 =A0 WRITE (*, '(3PE10.4)' ) X
> > END
>
> > produces:
>
> > 0.1230E-01
> > 1.2300E-02
> > 12.300E-03
> > 123.00E-04
>
> At the end, the talk was about kpFw.d. =A0What is the result if you use F
> instead of E in the formats?
>
> Dick Hendrickson

Dick,
 The routine decides if an F format can give better precision for a
passed value V, for a given total width IW, or if an E format is
needed. Robin points out that D formats would be better for double
precision, but the same rules apply for both E and D outputs and the
problem was that two compilers give different displays with the F
format; one with a leading zero before the decimal point, one without.
Processing the string without knowing which output version could be
present increases the program length and reduces efficiency and may
NOT poduce the optimum result and correct rounding.

So both -0.12346 and -.123457 are possible strings. So the program has
the problem of two possible results for width 8 with the same value
-1.234567890e-01 as input.

Just a point (not raised above). I am testing a methodt that is
supposed to work even with F77 non-full standard compilers in order to
try for a general solution to the posited query.
Complaints about my coding style may not always be relevant.

On Nov 20, 5:39=A0pm, Terence <tbwri...@cantv.net> wrote:
> On Nov 19, 10:40=A0am, Dick Hendrickson <dick.hendrick...@att.net>
> wrote:
>
>
>
>
>
> > On 11/18/10 5:04 PM, robin wrote:
>
> > > "Terence"<tbwri...@cantv.net> =A0wrote in messagenews:1bd3cbfd-6eec-4=
e51-b275-bca45faa7b79@r6g2000vbf.googlegroups.com...
> > > |
> > > | =A0 =A0 =A0PROGRAM FORMAT
> > > | =A0 =A0 =A0REAL*8 =A0 R
>
> > > REAL*8 isn't portable.
>
> > > | =A0 =A0 =A0R=3D123.4567890E-10
> > > | =A0 =A0 =A0WRITE(*,1) R
> > > | =A0 =A01 FORMAT('>',0PE15.9.'< =A0EXPECT>-.123456789E-07< =A0')
> > > | =A0 =A0 =A0END
> > > |
> > > | This little test is causing different results with at least two
> > > | different compilers.
> > > | MS Fortran gives a leading negative sign, a dot and the rest of the
> > > | digits, with an updated exponent (as my MS manual defines precisely
> > > | that use of the zero scale in E formats and as shown in the output
> > > | text field)..
> > > |
> > > | A CVF compiler reportedly (I'm informed, haven't run it myself) los=
es
> > > | the sign, and with a longer field length would give (gives) a leadi=
ng
> > > | negative sign then a zero, then the decimal point and further digit=
s.
> > > |
> > > | My manual: =A0"For a scale factor of zero, the output field is a mi=
nus
> > > | sign (if necessary), followed by a decimal point, followed by a str=
ing
> > > | of digits, followed by an exponent field, (exp), of one of the
> > > | following forms....."
> > > |
> > > | A different interpretation of, for kPFw.d =A0 "k significant digits=
, a
> > > | dot, then d-k-1 digits followed by an exponent"? Could it be some
> > > | think a leading zero left of the dot is significant
> > > |
> > > | Does " k significant digits" mean none if k is zero? Or not?
> > > |
> > > | "k significant digits to the left of the decimal point, and d-k-1
> > > | places after the decimal point" .
> > > |
> > > | =A0i.e. w=3Dk+1+d+4 =A0 =A0for exponents needing 1 to 3 digits (Esd=
d or
> > > | sddd).
>
> > > =A0 =A0 REAL X
> > > =A0 =A0 X =3D 0.0123
> > > =A0 =A0 WRITE (*, '(0PE10.4)' ) X
> > > =A0 =A0 WRITE (*, '(1PE10.4)' ) X
> > > =A0 =A0 WRITE (*, '(2PE10.4)' ) X
> > > =A0 =A0 WRITE (*, '(3PE10.4)' ) X
> > > END
>
> > > produces:
>
> > > 0.1230E-01
> > > 1.2300E-02
> > > 12.300E-03
> > > 123.00E-04
>
> > At the end, the talk was about kpFw.d. =A0What is the result if you use=
 F
> > instead of E in the formats?
>
> > Dick Hendrickson
>
> Dick,
> =A0The routine decides if an F format can give better precision for a
> passed value V, for a given total width IW, or if an E format is
> needed. Robin points out that D formats would be better for double
> precision, but the same rules apply for both E and D outputs and the
> problem was that two compilers give different displays with the F
> format; one with a leading zero before the decimal point, one without.
> Processing the string without knowing which output version could be
> present increases the program length and reduces efficiency and may
> NOT poduce the optimum result and correct rounding.
>
> So both -0.12346 and -.123457 are possible strings. So the program has
> the problem of two possible results for width 8 with the same value
> -1.234567890e-01 as input.
>
> Just a point (not raised above). I am testing a methodt that is
> supposed to work even with F77 non-full standard compilers in order to
> try for a general solution to the posited query.
> Complaints about my coding style may not always be relevant.

 Just as an update. I arranged to pass two values, each with both
possible signs; one guaranteed to round up to 1.0 times a power of 10
on re-output, one just a simple .123456789 in the same way. Then all
four values were tested in double precision, with exponents from -999
to +999.

 It was quite interesting to see what happened in producing the
character strings; the formats of the four output types output did not
match up between each other and between the 'overflow' case and the
'normal' case.

 But always the 'overflow' case, wrote out the value shifted left one
character as opposed to the other which always started with at least
one blank before a negative sign if there was one (no sign option
selected, as if 'S').

 The only other observation was the difference between compiler
treatments were whether or not there was a leading zero between any
sign and the decimal point (which has been explained above by Richard
as an option for the compiler).

 So in the problem of optimizing precision output for a given field
size for tabules, the only soltion seems to be to predict a work size
area needed, generate a suitable remote format statement, use it to
get appropriate rounding for the desired field size, then parse the
work result to the final output field. Quite interesting logic paths
needed!

 And some resluts are surprising; some are best as F formats (no
exponent), some D (or E) formats vary surprisingly betwen exponets
differing by onle 1 (eg E9, E09, E10 may result).