Home > Archive > Fortran > December 2006 > Getting the decimal points to line up!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Getting the decimal points to line up!
|
|
| Ancient_Hacker 2006-12-15, 7:06 pm |
| Okay, we're in the 21st century, we should be driving sky-cars,
wearing aluminum foil clothes, and programming in a language that makes
it easy to LINE UP THE &^$&*%$**!! decimal points on the printouts.
This is what comes out from this statement
WRITE( UNIT = StdOut, FMT = "( 1X,1P,G15.6 )", ADVANCE = 'NO'
) V
1: -1.82405 -1.38282 -0.956946 -0.538771
-0.104165 0.341845
2: -1.25098 -0.619149 -0.196250 0.255411
0.581097 0.879818
3: -0.825875 -0.198933 4.748394E-02 0.248688
0.508482 0.914057
4: -0.407584 0.225743 0.372317 0.404308
0.570299 1.05813
5: 0.119758 0.808149 0.749159 0.574465
0.594599 1.08003
6: 0.746165 1.46579 1.09562 0.707811
0.607051 0.987560
7: 1.15024 1.84483 1.30328 0.767331
0.633309 1.00111
8: 1.18195 1.78742 1.31574 0.728740
0.495854 0.856861
... I see they may not line up on your browser. FYI they all line up
EXCEPT all the 1.xxx values, which are one column to the right.
grrrr......
| |
| meek@skyway.usask.ca 2006-12-15, 7:06 pm |
| In a previous article, "Ancient_Hacker" <grg2@comcast.net> wrote:
>Okay, we're in the 21st century, we should be driving sky-cars,
>wearing aluminum foil clothes, and programming in a language that makes
>it easy to LINE UP THE &^$&*%$**!! decimal points on the printouts.
>
>
>This is what comes out from this statement
>
> WRITE( UNIT = StdOut, FMT = "( 1X,1P,G15.6 )", ADVANCE = 'NO'
> ) V
>
> 1: -1.82405 -1.38282 -0.956946 -0.538771
> -0.104165 0.341845
> 2: -1.25098 -0.619149 -0.196250 0.255411
> 0.581097 0.879818
> 3: -0.825875 -0.198933 4.748394E-02 0.248688
> 0.508482 0.914057
> 4: -0.407584 0.225743 0.372317 0.404308
> 0.570299 1.05813
> 5: 0.119758 0.808149 0.749159 0.574465
> 0.594599 1.08003
> 6: 0.746165 1.46579 1.09562 0.707811
> 0.607051 0.987560
> 7: 1.15024 1.84483 1.30328 0.767331
> 0.633309 1.00111
> 8: 1.18195 1.78742 1.31574 0.728740
> 0.495854 0.856861
>
>.. I see they may not line up on your browser. FYI they all line up
>EXCEPT all the 1.xxx values, which are one column to the right.
>grrrr......
>
In addition - the 1.xxxx numbers don't have 6 decimal places
Chris
| |
| Michel Olagnon 2006-12-15, 7:06 pm |
| m @skyway.usask.ca wrote:
> In a previous article, "Ancient_Hacker" <grg2@comcast.net> wrote:
>
>
> In addition - the 1.xxxx numbers don't have 6 decimal places
>
Why would you expect them to ?
The standard states that when Gk.d is in the range where an F format is used,
d means something like "significant digits". If you want the decimal points
to line up, use an F format when you can (knowing the range), an E format
otherwise. G means "I don't care about cute printing".
| |
| Richard E Maine 2006-12-15, 7:06 pm |
| <m@skyway.usask.ca> wrote:
> In addition - the 1.xxxx numbers don't have 6 decimal places
P and G have a "strange" interaction. I am personally convinced that
this was the result of an off-by-one typo in f77. I once (long before I
was on the committee or knew anyone who was) submitted a comment about
this, which I considered to be an error in f77. Unfortunately, all the
vendors had apparently long since implemented exactly what the standard
specified rather than questioning it. Thus, the standard was left alone
as odd, but at least consistent across implementations. The "feature"
really makes no sense at all. I can see no coherent rationalization and
I've never heard anyone else propose one that holds up to even casual
inspection. I'll stick with my typo theory.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Terence 2006-12-15, 7:06 pm |
| I've always called my own edit functions, specifying the position in,
and field length within the report line character string and and the
number of decimal desired (and what to produce if zero occurred or a
values too small to be written). I can also comma-divide and float
currency simbols.
Then I output the report line string.
CALL EDIT(float,len,ndec,str(ipos),kcode)
CALL FDIT(int,len,str(ipos),kcode)
I do something similar for integer values, just to be consistent.
It makes reporting a stress-free process.
| |
| glen herrmannsfeldt 2006-12-15, 7:06 pm |
| Richard E Maine <nospam@see.signature> wrote:
> <m@skyway.usask.ca> wrote:
[color=darkred]
> P and G have a "strange" interaction. I am personally convinced that
> this was the result of an off-by-one typo in f77. I once (long before I
> was on the committee or knew anyone who was) submitted a comment about
> this, which I considered to be an error in f77. Unfortunately, all the
> vendors had apparently long since implemented exactly what the standard
> specified rather than questioning it.
You mean the default for E format (as used for G with large or small
values) of a zero before the decimal point, instead of the most significant
digit? It seems that goes back to Fortran I. I was a little surprised
to see P went back that far. The effect of P on F and E descriptors
goes back to Fortran I, I believe that G came later. When G was added,
it assumed the attributes that F and E already had, except (fortunately)
that P doesn't affect F-like formatting under G.
I suppose it could have changed when f66 was standardized, but after
that I would say it was too late.
-- glen
| |
| Richard E Maine 2006-12-15, 10:04 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> Richard E Maine <nospam@see.signature> wrote:
>
>
>
> You mean the default for E format (as used for G with large or small
> values) of a zero before the decimal point, instead of the most significant
> digit?
No. Nothing to do with that. And nothing that has any traceable
connection with anything else. As I said, there is no coherent
explanation. Being consistent with previous things would be a coherent
explanation. It has *ONLY* to do with G in combination with P - nothing
else is related in any way.
I don't have the material in front of me and don't feel like taking the
time to look it up (particularly from my laptop while on vacation). With
G and P (well, other than P0), the number of significant figures is
different depending on whether the G uses E or F format. It is not
different without the P. There is a spot in the standard where changing
one formula to bias it by 1 would give the "obvious" answer. The d in
Gw.d is supposed to be the number of significant digits, but because of
this error, it isn't, and the number of significant digits depends on
the magnitude of the value printed, which is what the OP noted.
> It seems that goes back to Fortran I.
Not the effect I'm talking about. It doesn't go back to anything
pre-f77. If you think it does, then you haven't found the effect in
question.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-12-16, 10:05 pm |
| Richard E Maine <nospam@see.signature> wrote:
(snip, I wrote)
(snip)
[color=darkred]
> I don't have the material in front of me and don't feel like taking the
> time to look it up (particularly from my laptop while on vacation). With
> G and P (well, other than P0), the number of significant figures is
> different depending on whether the G uses E or F format. It is not
> different without the P.
Well from Fortran 66:
I believe the way it works is that when G uses the equivalent
of E or D then Gw.d gives either Ew.d or Dw.d. That seems reasonable.
In that case, d is not the number of significant digits, but the
number after the decimal point. Without P, (or with 0P) for
E and D there is a 0 before the decimal point, and significant
digits after, so d is also the number of significant digits.
With nP, n not zero, d is the number of digits after decimal
point, and not the number of significant digits. To me the
mistake was making the default zero before the decimal instead
of the first significant digit.
> There is a spot in the standard where changing
> one formula to bias it by 1 would give the "obvious" answer. The d in
> Gw.d is supposed to be the number of significant digits, but because of
> this error, it isn't, and the number of significant digits depends on
> the magnitude of the value printed, which is what the OP noted.
[color=darkred]
> Not the effect I'm talking about. It doesn't go back to anything
> pre-f77. If you think it does, then you haven't found the effect in
> question.
For large or small values, Gw.d gives Ew.d or Dw.d using the
same rules as Fortran I, where d is significant digits only
when the scale factor is zero. It does seem that the rules
could have been done better.
-- glen
| |
| Richard E Maine 2006-12-16, 10:05 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> Well from Fortran 66:
I don't understand what the "from Fortran 66" refers to, since what
follows is about G, which doesn't exist in f66.
> I believe the way it works is that when G uses the equivalent
> of E or D then Gw.d gives either Ew.d or Dw.d.
No. That is not what happens. That isn't even close. I don't
particularly feel like quoting the standard to you. It is available to
read. And that bit is a bit complicated to quote. If you look at what
the standard actually says, and carefully work it through, you will see
the problem I mentioned. If you make incorrect gueses about what it
says, you won't get anywhere. There is simply no way you will just guess
what the standard says on this without reading it.
> That seems reasonable.
So you make a guess about what the standard might reasonably say and
then conclude that if it follows your guess it would be reasonable?
Sorry, but such circularity isn't worth discussing. And teh premise is
wrong.
> For large or small values, Gw.d gives Ew.d or Dw.d..
It does not.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-12-17, 4:12 am |
| Richard E Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
[color=darkred]
> I don't understand what the "from Fortran 66" refers to, since what
> follows is about G, which doesn't exist in f66.
(Text from the standards in quotes, my discussions of them
outside of quotes.)
Fortran 66, "7.2.3.6.2: Real Conversions: There are three conversions
available for use with real data: F, E, and G."
and later:
"7.2.3.6.2.2 The scale factor n controls the decimal normalization
between the number part and the exponent part such that:
(1) If n<=0, there will be exactly -n leading zeros and d+n
significant digits after the decimal point.
(2) If n>0, there will be exactly n significant digits to
the left of the decimal point and d-n+1 to the right of
the decimal point.
The numeric field descriptor Gw.d indicates that the
external field occupies w positions with d significant
digits."
So for n>0, d+1 significant digits are printed, the leading
zero for n<=0 is not printed.
[color=darkred]
> No. That is not what happens. That isn't even close. I don't
> particularly feel like quoting the standard to you. It is available to
> read. And that bit is a bit complicated to quote. If you look at what
> the standard actually says, and carefully work it through, you will see
> the problem I mentioned. If you make incorrect gueses about what it
> says, you won't get anywhere. There is simply no way you will just guess
> what the standard says on this without reading it.
Continuing from 7.2.3.6.2.2:
"Magnitude of Datum Equivalent conversion
0.1 <= N < 1 F(w-4).d, 4X
1 <= N < 10 F(w-4).(d-1), 4X
....
10**(d-1)<= N < 10**d F(w-4).0, 4X
Otherwise sEw.d
Note that the scale factor is suspended unless the magnitude
of the datum to be converted is outside of the range that
permits effective use of F conversion."
[color=darkred]
> So you make a guess about what the standard might reasonably say and
> then conclude that if it follows your guess it would be reasonable?
> Sorry, but such circularity isn't worth discussing. And teh premise is
> wrong.
I was reading from Fortran 66 when I wrote the previous post,
and again in writing this one.
[color=darkred]
> It does not.
It does. From Fortran 77 13.5.9.2.3 "G Editing"
"If N<0.1 or N>=10**d, Gw.d output editing is the same as kPEw.d
output editing and Gw.dEe output editing is the same as kPEw.dEe
output editing, where k is the scale factor currently in effect.
If N is greater than or equal to 0.1 and is less than 10**d,
the scale factor has no effect, and the value of N determines
the editing as follows:"
(the same as I quoted from Fortran 66 above without e, or with e=2,
otherwise adjusted to accomodate e.)
The rules for E editing with scale factor are pretty much
like those in Fortran I with some interesting changes.
"For E and F-conversion, the number of places (d) after the
decimal point that are to be rounded and printed. If d is
not less than 10 it is treated mod 10."
(the mod 10 being an interesting difference.)
"A postive scale factor may also be used with E conversion to
increase the number and decrease the exponent. Thus FORMAT
(I2, 1P3E12.4) would give with the same data
27 -9.3210E 01 -7.5804E-03 5.5361E-01
NOTE: The scale factor is assumed to be zero if no other
value has been given. However, once a value has been given
it will hold for all F and E-conversions until a new one
is given. The scale factor has no effect on I conversion."
So, already in Fortran I with E conversion and a positive
scale factor you get d+1 significant digits, but only
d significant digits for zero or negative scale factor.
I don't know if versions with G existed before 1966,
and motivated the standard. It could have given d+1
significant digits when doing F-like conversions,
but did not. Putting one significant digit
before the decimal point, the convention for
scientific notation at least when I learned it, would
have also made sense. That mistake was made around 1956.
On an unrelated note, the Knuth book mentioned in previous posts
about the history of programming languages mentions Fortran 0,
that is, as it was documented before they started writing the compiler.
-- glen
| |
| Dick Hendrickson 2006-12-17, 10:05 pm |
| Richard E Maine wrote:
> <m@skyway.usask.ca> wrote:
>
>
> P and G have a "strange" interaction.
There are two simple rules for using the P edit descriptor.
1) If you are using old working code that uses a P, don't
mess with it.
2) If you are writing new code, don't use a P.
Follow those rules and you can't go wrong.
Dick Hendrickson
To elaborate slightly; the P descriptor is a holdover from the good
old days when input (and machine readable output) was an 80 column
punched card. "Wasting" a column for a mere "." was a sin. A person
who truly understood the P descriptor could save thousands of columns,
cards, microseconds, or trees. Other people wrote programs that didn't
work or thet unnecessarily killed trees.
| |
| John Harper 2006-12-17, 10:05 pm |
| In article <skmhh.516096$QZ1.34046@bgtnsc04-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:
>Richard E Maine wrote:
>
>There are two simple rules for using the P edit descriptor.
>
>1) If you are using old working code that uses a P, don't
> mess with it.
>
>2) If you are writing new code, don't use a P.
>
>Follow those rules and you can't go wrong.
Having been brought up to write a digit in front of a decimal point,
and finding that 1.2E+09 is easier to comprehend and uses less space
than 0.12E+10, I would amend rule 2 to say
2) If you are writing new code, use a P only if you also use an E,
in which case you should use 1P,E (or 1P,nE if you were thinking
of using nE). If there is an F after that, you should use 0P,F
(or 0P,nE) there.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| Gary Scott 2006-12-17, 10:05 pm |
| John Harper wrote:
> In article <skmhh.516096$QZ1.34046@bgtnsc04-news.ops.worldnet.att.net>,
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
>
> Having been brought up to write a digit in front of a decimal point,
> and finding that 1.2E+09 is easier to comprehend and uses less space
> than 0.12E+10, I would amend rule 2 to say
>
> 2) If you are writing new code, use a P only if you also use an E,
> in which case you should use 1P,E (or 1P,nE if you were thinking
> of using nE). If there is an F after that, you should use 0P,F
> (or 0P,nE) there.
except after e and sometimes y...
>
> -- John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
In observation of the Supercomputer Conference 2006, Steve Lionel of
Intel wrote:
"What struck me, as I wandered the show floor, is that Fortran, a
fifty-year-old language considered long-dead by many, has a customer
base vibrant enough to support (at least) seven commercial vendors
offering compilers on the same platforms, plus two (why two?) competing
open source compiler projects! What other widely-adopted programming
language can say the same?"
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| James Giles 2006-12-17, 10:05 pm |
| John Harper wrote:
> In article
> <skmhh.516096$QZ1.34046@bgtnsc04-news.ops.worldnet.att.net>, Dick
> Hendrickson <dick.hendrickson@att.net> wrote:
....>> 2) If you are writing new code, don't use a P.
>
> Having been brought up to write a digit in front of a decimal point,
> and finding that 1.2E+09 is easier to comprehend and uses less space
> than 0.12E+10, I would amend rule 2 to say
>
> 2) If you are writing new code, use a P only if you also use an E,
> in which case you should use 1P,E (or 1P,nE if you were thinking
> of using nE). If there is an F after that, you should use 0P,F
> (or 0P,nE) there.
No, leave rule 2 alone. Don't use P. Instead use ES. The
ES specifier is nearly identical to the E specifier except that
it writes one digit before the decimal, rather than zero.
It's been standard for 15+ years. It ignores the scale factor
(so if you use P, it doesn't matter).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-12-18, 4:13 am |
| Dick Hendrickson <dick.hendrickson@att.net> wrote:
> There are two simple rules for using the P edit descriptor.
> 1) If you are using old working code that uses a P, don't
> mess with it.
> 2) If you are writing new code, don't use a P.
> Follow those rules and you can't go wrong.
> To elaborate slightly; the P descriptor is a holdover from the good
> old days when input (and machine readable output) was an 80 column
> punched card. "Wasting" a column for a mere "." was a sin.
Hmmm. Without P, D or E format waste one column with a leading
zero before the decimal point. Also, with G format when
using E-like conversion. Also, if you are reading data without
an explicit decimal point, the d in Fw.d determines the implied
decimal location, so usually no P is needed. I suppose you can
still use P if the decimal point is so far off that d can't
account for it.
-- glen
| |
| Dick Hendrickson 2006-12-18, 7:08 pm |
| John Harper wrote:
> In article <skmhh.516096$QZ1.34046@bgtnsc04-news.ops.worldnet.att.net>,
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
> Having been brought up to write a digit in front of a decimal point,
> and finding that 1.2E+09 is easier to comprehend and uses less space
> than 0.12E+10, I would amend rule 2 to say
>
> 2) If you are writing new code, use a P only if you also use an E,
> in which case you should use 1P,E (or 1P,nE if you were thinking
> of using nE). If there is an F after that, you should use 0P,F
> (or 0P,nE) there.
Yes, but with the proper definition of "after" :(. In something like
print 10, a,b,c
10 format (f10.2, 1P, e20.10)
The bleeping 1P wraps around to the leading f10.2 when format reversion
happens.
Dick Hendrickson
>
> -- John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
|
|
|
|
|