Fortran - formatted output

Author

formatted output

s.z.s@web.de

2006-01-24, 7:02 pm

Hi!

I want to print 15 real values, so I do

<snip>
real, dimension(15) :: r_tmp
r_tmp=0 !or sth. usefull
write(*,111) r_tmp
111 format (15(F9.6,/))
<snap>

now I want to print a arbitrary number of numbers so I tried

<snip>
integer :: n
real, dimension(15) :: r_tmp !I know this can be done by allocating
memory dynamically
r_tmp=0 !or sth. usefull
write(*,111) r_tmp
111 format (n(F9.6,/))
<snap>

and it didn't work. Is there an elegant way to do this?

Thanks, szs

s.z.s@web.de

2006-01-24, 7:02 pm

forgot one line... of course I set n=15 before using it.

szs

Michel OLAGNON

2006-01-24, 7:02 pm

s.z.s@web.de wrote:
> Hi!
>
> I want to print 15 real values, so I do
>
> <snip>
> real, dimension(15) :: r_tmp
> r_tmp=0 !or sth. usefull
> write(*,111) r_tmp
> 111 format (15(F9.6,/))
> <snap>
>
> now I want to print a arbitrary number of numbers so I tried
>
> <snip>
> integer :: n
> real, dimension(15) :: r_tmp !I know this can be done by allocating
> memory dynamically
> r_tmp=0 !or sth. usefull
> write(*,111) r_tmp
> 111 format (n(F9.6,/))
> <snap>
>
> and it didn't work. Is there an elegant way to do this?
>
> Thanks, szs
>

I think that in that case, either omitting n or using
111 format (9999(F9.6,/)) should work.
If the format does not allow to output all the values
in the list, it is re-used from the last left parenthesis
in it. If the list is shorter than the format would allow,
the remaining is not used, that's all.

Michael Metcalf

2006-01-24, 7:02 pm

<s.z.s@web.de> wrote in message
news:1138114434.666989.140430@g49g2000cwa.googlegroups.com...
> integer :: n
> real, dimension(15) :: r_tmp !I know this can be done by allocating
> memory dynamically
> r_tmp=0 !or sth. usefull
> write(*,111) r_tmp
> 111 format (n(F9.6,/))
> <snap>
>
> and it didn't work. Is there an elegant way to do this?
>
The easy way is to use, say, 99(F9.6,/), i.e. some arbitrarily high number.
You can also define formats at run time (see "Fortran 95/2003 Explained",
Section 9.4), but that's probably overkill in this situation.

Regards,

Mike Metcalf

Paul Van Delst

2006-01-24, 7:02 pm

s.z.s@web.de wrote:
> Hi!
>
> I want to print 15 real values, so I do
>
> <snip>
> real, dimension(15) :: r_tmp
> r_tmp=0 !or sth. usefull
> write(*,111) r_tmp
> 111 format (15(F9.6,/))
> <snap>
>
> now I want to print a arbitrary number of numbers so I tried
>
> <snip>
> integer :: n
> real, dimension(15) :: r_tmp !I know this can be done by allocating
> memory dynamically
> r_tmp=0 !or sth. usefull
> write(*,111) r_tmp
> 111 format (n(F9.6,/))
> <snap>
>
> and it didn't work. Is there an elegant way to do this?

Just leave out the "n" in the format statement. Since you're printing each value on a
different line, that seems to be the easiest solution:

program testfmt
integer,parameter :: n=15
real, dimension(n) :: r_tmp
r_tmp=0
write(*,111) r_tmp
111 format ((F9.6,/))
end program testfmt

lnx:scratch : g95 testfmt.f90
lnx:scratch : a.out
0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

0.000000

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

s.z.s@web.de

2006-01-24, 7:02 pm

Thank you, Michel and Michael, both of you helped me!

szs

Richard E Maine

2006-01-24, 7:02 pm

Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:

> Just leave out the "n" in the format statement. Since you're printing each
> value on a different line, that seems to be the easiest solution:
....
> 111 format ((F9.6,/))

And the extra parens then become superfluous. Finally, you can probably
leave out the ",/" bit, depending what you intend. That has the effect
of double-spacing everything. If the double-spacing is intentional,
fine. But I wonder if this might be from a mistaken notion that you have
to specify every newline (as in C). If you don't want the double
spacing, then

111 format(f9.6)

would seem to be the simplest and most natural form.

--
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

Colin Watters

2006-01-24, 7:02 pm

"Richard E Maine" <nospam@see.signature> wrote in message
news:1h9nrz1.12t1mlrcg3uf2N%nospam@see.signature...

<snip>

>If you don't want the double
> spacing, then
>
> 111 format(f9.6)
>
> would seem to be the simplest and most natural form.

.... or (IMHO nicer):

write(*,'(f9.6)') r_tmp

who needs those nasty statement labels and explicit formats?

--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk

> Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:
>
each[color=darkred]
> ...
>
> And the extra parens then become superfluous. Finally, you can probably
> leave out the ",/" bit, depending what you intend. That has the effect
> of double-spacing everything. If the double-spacing is intentional,
> fine. But I wonder if this might be from a mistaken notion that you have
> to specify every newline (as in C). >
> --
> 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

Catherine Rees Lay

2006-01-25, 4:12 am

Colin Watters wrote:
> "Richard E Maine" <nospam@see.signature> wrote in message
> news:1h9nrz1.12t1mlrcg3uf2N%nospam@see.signature...
>
> <snip>
>
>
> ... or (IMHO nicer):
>
> write(*,'(f9.6)') r_tmp
>
> who needs those nasty statement labels and explicit formats?
>

Well, in a trivial case, I'd agree. But if you have a lot of very
similar write statements all using f9.6, it's so very much simpler to
change if the format's in just one place. Especially if you have two
separate sorts of output (say, temperatures and coordinates) which both
use the same format now, but then your end-user decides they want more
digits output just for the temperatures.

Catherine.

beliavsky@aol.com

2006-01-25, 7:10 pm

Catherine Rees Lay wrote:
> Colin Watters wrote:

>
> Well, in a trivial case, I'd agree. But if you have a lot of very
> similar write statements all using f9.6, it's so very much simpler to
> change if the format's in just one place. Especially if you have two
> separate sorts of output (say, temperatures and coordinates) which both
> use the same format now, but then your end-user decides they want more
> digits output just for the temperatures.

One could define a character string

fmt_r = "(f9.6)"

and then use it instead of the FORMAT statement, which is archaic IMO,
agreeing with Colin. Format strings can be read from input files.
Furthermore, maybe the program user does not know Fortran format codes,
but he does know that he wants 6 decimal places and for the number to
fit in 9 columns. In that case the format string can be built within
the program.

Colin Watters

2006-01-25, 7:10 pm

<beliavsky@aol.com> wrote in message
news:1138205231.016887.54760@g44g2000cwa.googlegroups.com...
> Catherine Rees Lay wrote:
>
>
> One could define a character string
>
> fmt_r = "(f9.6)"
>
> and then use it instead of the FORMAT statement, which is archaic IMO,
> agreeing with Colin. Format strings can be read from input files.
> Furthermore, maybe the program user does not know Fortran format codes,
> but he does know that he wants 6 decimal places and for the number to
> fit in 9 columns. In that case the format string can be built within
> the program.
>

One can define a character array and set its values at compile time, eg:

character*80 :: fmt(2) =
/('(f10.3,f10.4,f10.4)','(f10.0,f10.1,f10.2)')/

and then use one or other element, depending on an integer N, eg:

write(6,fmt(N)) rho,visc,cp

My code uses this construct extensively to select the correct descriptor for
a given set of unit classes; n=1 for SI units, n=2 for imperial units. Its a
bit inflexable though and I'm slowly replacing all the write statements like
these with references to a function that chooses the format depending on the
magnitude of the quantity (see the thread "Is there a Fortran feature to do
this?").

--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk

Richard E Maine

2006-01-25, 7:10 pm

Colin Watters <qolin.see_signature@nowhere.co.uk> wrote:

> One can define a character array and set its values at compile time, eg:
>
> character*80 :: fmt(2) =
> /('(f10.3,f10.4,f10.4)','(f10.0,f10.1,f10.2)')/

While this is ok as is, be aware that this construct is very picky. The
lengths of all of the strings in a constructor have to be exactly equal.
They are equal in the above (I think), but change one of those f10's to
an f9 and they wouldn't be unless you remembered to add the right amount
of explicit blank padding.

Though I generally prefer to use initializers instead of data
statements, this is one of the areas where data statements do work
nicely. With a data statement, you don't need to use an array
constructor; each element gets individually padded. In f2003 there is
also a solution for array constructors. The solution is a bit verbose,
but it beats manually counting characters. The verbosity does buy
complete generality and lack of context-dependent quirks.

character*80 :: fmt(2) = &
[character*80::'(f10.3,f10.4,f10.4)','(f10.0,f10.1,f10.2)']

--
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

robin

2006-01-25, 7:10 pm

Michel OLAGNON wrote in message <43D6416C.5050003@ifremer-a-oter.fr>...
>s.z.s@web.de wrote:
[color=darkred]
>I think that in that case, either omitting n or using
>111 format (9999(F9.6,/)) should work.

This isn't going tro do anything different from
the first example, namely, it will print one value
each second line.
To print more than one value per line, it would have to
be written
111 FORMAT(15F9.6)
as shown in my previous post.
Note that extra parentheses are not required.

>If the format does not allow to output all the values
>in the list, it is re-used from the last left parenthesis
>in it. If the list is shorter than the format would allow,
>the remaining is not used, that's all.

You are thinking of a different case, where other variables
or text are printed as well, for example
write (*, 222) n, x
222 format (I5, (15F9.6))
In this case, if more than 15 values of x are printed,
the format is re-used from the parenthesis just before '15'.
This format gives up to 15 values per line.
a repeat factor like 9999 is not required.

robin

2006-01-25, 7:10 pm

s.z.s@web.de wrote in message <1138114434.666989.140430@g49g2000cwa.googlegroups.com>...
>Hi!
>
>I want to print 15 real values, so I do
>
><snip>
>real, dimension(15) :: r_tmp
>r_tmp=0 !or sth. usefull
>write(*,111) r_tmp
>111 format (15(F9.6,/))
><snap>

This will print one value on each line.
For that you need only
111 format(F9.6)

>now I want to print a arbitrary number of numbers so I tried
><snip>
>integer :: n
>real, dimension(15) :: r_tmp !I know this can be done by allocating
>memory dynamically
>r_tmp=0 !or sth. usefull
>write(*,111) r_tmp
>111 format (n(F9.6,/))
><snap>
>
>and it didn't work. Is there an elegant way to do this?

This won't work.
But
111 format(F9.6)
will work as above.

If, however, you want, say, up to 15 values per line:
111 format (15F9.6)
will do that for any N as large as you want.
A new line is started after 15 values have been printed.

>Thanks, szs

robin

2006-01-25, 7:10 pm

Michael Metcalf wrote in message <_mrBf.3852$yE4.3276@news-wrt-01.rdc-nyc.rr.com>...
>
><s.z.s@web.de> wrote in message
>news:1138114434.666989.140430@g49g2000cwa.googlegroups.com...
>The easy way is to use, say, 99(F9.6,/),

This won't do anything that the example above doesn't do.
It will still print one value every second line.
In other words, the '99' is unnecessary.

> i.e. some arbitrarily high number.

Rich Townsend

2006-01-25, 7:10 pm

robin wrote:
> Michael Metcalf wrote in message <_mrBf.3852$yE4.3276@news-wrt-01.rdc-nyc.rr.com>...
>
>
>
> This won't do anything that the example above doesn't do.
> It will still print one value every second line.
> In other words, the '99' is unnecessary.

No, you are wrong. The example given by Mike Metcalf will print one value every
line (assuming n is less than 99), followed by a final blank line. Omitting the
99 will produce a blank line between every value (ie, double spacing). A simple
test program suffices to show this.

cheers,

Rich

John Harper

2006-01-25, 7:10 pm

In article <1h9q7dh.b9z8xgn5gjktN%nospam@see.signature>,
Richard E Maine <nospam@see.signature> wrote:
>
> In f2003 ...
>
> character*80 :: fmt(2) = &
> [character*80::'(f10.3,f10.4,f10.4)','(f10.0,f10.1,f10.2)']

I have occasionally been burnt by the scalar equivalent of the above
when a format turned out to be longer than 80 characters. In f2003,
can one avoid _all_ the manual counting if fmt is a named constant,
with length (*) ? For example, I'm not sure if this would be OK:

character*(*),parameter :: fmt(2) = &
[character*(*)::'(f10.3,f10.4,f10.4)','(f10.0,f10.1)']

Note that in this example the strings have different lengths. I would
hope that fmt was given the length of its longest element, and that
shorter elements were padded with blanks.
--
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Richard Maine

2006-01-25, 9:58 pm

John Harper <harper@mcs.vuw.ac.nz> wrote:

> with length (*) ? For example, I'm not sure if this would be OK:
>
> character*(*),parameter :: fmt(2) = &
> [character*(*)::'(f10.3,f10.4,f10.4)','(f10.0,f10.1)']
>
> Note that in this example the strings have different lengths. I would
> hope that fmt was given the length of its longest element, and that
> shorter elements were padded with blanks.

No that's not ok. You can't use character*(*) in the array constructor.
If that actually worked for all the cases, then you wouldn't need it at
all. It can get *VERY* tricky to actually get all the cases right
without forcing the compiler to do really ludicrous things. That's
exactly what I was referring to when I said that the verbosity buys
complete generality and lack of context-dependent quirks.

I forget all the details, but they get very nasty in general. Maybe the
bad cases can't come up in initialization expressions, but they sure do
in general expressions (and array constructors aren't special-cased for
initialization expressions).

It is that business of finding what the longest element is. Trivial, of
course, with literal strings like this. Not so trivial when the string
length can depend on function evaluations, and there are implied DO
loops - zero-length ones can be extra nasty.

Anyway, long-winded explanations aside, no the instance inside of the
array constructore is not one of the very few places where you can use
character*(*). You probably could get by with

character*(*),parameter :: fmt(2) = &
[character*80::'(f10.3,f10.4,f10.4)','(f10.0,f10.1)']

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

Ken Plotkin

2006-01-26, 3:59 am

On 25 Jan 2006 08:07:11 -0800, beliavsky@aol.com wrote:

>One could define a character string
>
>fmt_r = "(f9.6)"
>
>and then use it instead of the FORMAT statement, which is archaic IMO,
[snip]

I think you're verging on re-inventing self-modifying code, which
really is archaic.

I agree very strongly with Catherine's point. Also, by using format
statements you have a set of fixed templates - no need to check
everywhere to see if the variable holding the format has been changed.

Ken Plotkin

David Jones

2006-01-26, 7:58 am

Ken Plotkin wrote:
> On 25 Jan 2006 08:07:11 -0800, beliavsky@aol.com wrote:
>
>
>
> I think you're verging on re-inventing self-modifying code, which
> really is archaic.
>
> I agree very strongly with Catherine's point. Also, by using format
> statements you have a set of fixed templates - no need to check
> everywhere to see if the variable holding the format has been
changed.
>

.... also, explicit format statements can be subject to compile-time
checking, depending I suppose on the compiler. Is compile-time
checking implemented by any compiler for the other form, assuming that
it was feasible to recognise that a format-string was constant?

David Jones

Dan Nagle

2006-01-26, 7:58 am

David Jones wrote:

<snip a bunch>

> ... also, explicit format statements can be subject to compile-time
> checking, depending I suppose on the compiler. Is compile-time
> checking implemented by any compiler for the other form, assuming that
> it was feasible to recognise that a format-string was constant?

Compilers are required to check formats in format statements,
some will check formats in literal or named character constants.

See Section 1.5, following the list.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

beliavsky@aol.com

2006-01-26, 7:58 am

David Jones wrote:
> Ken Plotkin wrote:
> changed.
>
> ... also, explicit format statements can be subject to compile-time
> checking, depending I suppose on the compiler. Is compile-time
> checking implemented by any compiler for the other form, assuming that
> it was feasible to recognise that a format-string was constant?
>
> David Jones

beliavsky@aol.com

2006-01-26, 7:58 am

[My other reply did not appear correctly.]

It appears that some compilers do not check either FORMAT statements or
format strings at compile time. Consider the program below, which was
compiled online at http://www.lahey.com/cgi-bin/check.pl, using LF95
5.0 with the -f95 option, and also using g95 -std=f95. All of the
compilers gave only run-time errors. Are they violating the standard?

Lahey/Fujitsu Fortran 95 Source Check Output
Compiling program unit xcheck_format at line 1:
Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.

--------------------------------------------------------------------------------

Lahey/Fujitsu Fortran 95 Listing and Cross Reference

Source file : SOURCE.F90

Main program "xcheck_format"
(line-no.)(nest)
1 program xcheck_format
2 implicit none
3 character (len=*), parameter :: fmt_i="(i4)"
4 real :: x=0.0
5 write (*,fmt_i) 1.0
6 write (*,11) 1.0
7 write (*,fmt_i) x
8 write (*,11) x
9 11 format (i4)
10 end program xcheck_format

Jan Vorbrüggen

2006-01-26, 7:58 am

I would understand if the standard required the format to be checked for
syntactical correctness. I don't believe the standard requires it to be
checked for semantic correctness, as this cannot be done at compile time
for all cases - a simple one being mixing integer and floating format items
with an I/O list that contains an array section of one kind whose length
can only be determined at run time. In such cases, the standard usually
formulates a constraint on the program - which really means the programmer
- and not on the processor. As your example is of this category, I still
believe those compilers to be standard-conforming.

Jan

Herman D. Knoble

2006-01-26, 7:02 pm

Richard E Maine

2006-01-26, 7:03 pm

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:

> I would understand if the standard required the format to be checked for
> syntactical correctness. I don't believe the standard requires it to be
> checked for semantic correctness, as this cannot be done at compile time
> for all cases

Agree. But I can support that based on the standard instead of just on
arguments about "compile time". While the thought of "compile time" was
definitely in the minds of the committee when writing some parts
(anyway, I know it was in my mind), the standard intentionally avoids
using those actual words.

The actual words of relevance here are in item (3) of 1.5, which is what
requires the diagnosis. That item specifically requires cites the
numbered syntax rules and constraints. Semantic correctness (and in
particular, matching of the I/O-list and edit descriptors) is not part
of the numbered syntax rules and constraints.

> As your example is of this category, I still
> believe those compilers to be standard-conforming.

Agree.

--
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

robin

2006-01-26, 7:03 pm

Rich Townsend wrote in message ...
>robin wrote:
[color=darkred]
[color=darkred]
[color=darkred]
>No, you are wrong. The example given by Mike Metcalf will print one value every
>line (assuming n is less than 99),

Yes, it will print every line. But the principal point was
that the 99 is unnecessary [MM said "some arbitrarily high number".]
All that is required is f9.6
ie format(f9.6)
A repeat factor is, however, required to print more than one value
per line, which I think is what the OP wanted, and that is covered
in my other post. Even then, a large number is not required.

> followed by a final blank line. Omitting the
>99 will produce a blank line between every value (ie, double spacing).

Sponsored Links