Fortran - Allow * as a format string?

Author

Allow * as a format string?

Beliavsky

2008-01-24, 7:24 pm

I wish

write (some_unit,"*")

or

write (some_unit,"(*)")

(allowing for optional blank padding of the format string) could have
the same meaning as

write (some_unit,*)

This would provide a more unified syntax for write statements and
would also be convenient in subroutines where a format string has been
passed in as an optional argument. One could write

subroutine foo(format_str,...)
character (len=*), intent(in), optional :: format_str
character (len=100) :: format_str_
if (present(format_str)) then
format_str_ = format_str
else
format_str_ = "*"
end if
write (*,format_str_) some_data
write (some_unit,"*")

For subroutines that write output, I often pass the unit number as an
optional integer argument, and assing a local variable to that integer
or to 6 (suitably parameterized) if the argument is missing, since
write (*,*) is the same as write (6,*) on the platforms I use. I want
something analous for the asterisk "format".

glen herrmannsfeldt

2008-01-24, 7:25 pm

Beliavsky wrote:

> write (some_unit,"*")

(snip)

> write (*,format_str_) some_data

if(format_str.eq.'*') then
write(*,*) some_data
else
write(*,format_str) some_data
endif

-- glen

Beliavsky

2008-01-24, 7:25 pm

On Jan 24, 5:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Beliavsky wrote:
>
> (snip)
>
>
> if(format_str.eq.'*') then
> =A0 =A0 write(*,*) some_data
> else
> =A0 =A0 write(*,format_str) some_data
> endif
>
> -- glen

Yes, that is what I do. But if format_str were used in many places,
this would result in a lot of boilerplate code.

glen herrmannsfeldt

2008-01-24, 7:25 pm

Beliavsky wrote:

> On Jan 24, 5:07 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

[color=darkred]
[color=darkred]
[color=darkred]
> Yes, that is what I do. But if format_str were used in many places,
> this would result in a lot of boilerplate code.

To me, it would be slightly more important to have a numerical
value equivalent to unit *. Otherwise, you have four choices
for a given write statement:

write(*,*)
write(*,format)
write(unit,*)
write(unit,format)

On many machines it is equivalent to unit 6, but even so it
may be buffered separately.

Note, though, that the G edit descriptor is legal for REAL,
INTEGER, LOGICAL, or CHARACTER data. A format like '(6G20.14)'
will work with all intrinsic type, though with a fixed field
width even for CHARACTER variables.

-- glen

Richard Maine

2008-01-24, 7:25 pm

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

> Beliavsky wrote:
>
>
>
>
>
>
> To me, it would be slightly more important to have a numerical
> value equivalent to unit *.

Yes. I quite agree. The principles are simillar in that both are matters
of whether you have to hard-code in the syntax, with IF tests, or be
able to select with the run-time value of some variable. The hard-coded
syntax cascades badly if you have a lot of them. The unit number case
comes up more often in my experience (like pretty much all the time),
but I can see that the format one has simillar issues.

Note that f2003 finally solves the unit number one, by having the
output_unit and input_unit named constants. Those are guaranteed to get
you the same unit. True, that doesn't solve the problem retroactively,
fixing old codes and old compilers. But it does at least address it for
the future.

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

David Jones

2008-01-25, 8:20 am

Beliavsky wrote:
> On Jan 24, 5:07 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>=20
> Yes, that is what I do. But if format_str were used in many places,
> this would result in a lot of boilerplate code.

Some compilers allow (or have allowed) the rule that a format of the =
form

format_str=3D'( )'

(ie. nothing or just blanks between the parentheses) would gave the =
effect desired.

David Jones

Beliavsky

2008-01-25, 8:20 am

On Jan 25, 7:13=A0am, "David Jones" <dajx...@ceh.ac.uk> wrote:
> Beliavsky wrote:
>
>
>
>
>
>
> Some compilers allow (or have allowed) the rule that a format of the form
>
> format_str=3D'( )'
>
> (ie. nothing or just blanks between the parentheses) would gave the effect=
desired.

G95 allows

write (*,"()")

giving a blank line but not

write (*,"()") 2

giving the error message

Fortran runtime error: Exhausted data descriptors in format
()

I think it is standard-conforming in both cases. Intel Fortran behaves
similarly. Since the format string "()" is currently not legal if
there are items in the output list, redefining it so that

write (*,"()") a,b,c

is the same as

write (*,*) a,b,c

would not break any currently standard Fortran code, and it would
bring into conformance some code that used the vendor extension. Since
some vendors have already done it, it is obviously doable. Therefore
my revised suggestion is for a "()" format to mean the same as *.

Arjen Markus

2008-01-25, 7:21 pm

On 25 jan, 14:38, Beliavsky <beliav...@aol.com> wrote:
> On Jan 25, 7:13=A0am, "David Jones" <dajx...@ceh.ac.uk> wrote:
>
>
>
>
>
[color=darkred]
>
>
>
>
>
>
m[color=darkred]
>
>
ct desired.[color=darkred]
>
> G95 allows
>
> write (*,"()")
>
> giving a blank line but not
>
> write (*,"()") 2
>
> giving the error message
>
> Fortran runtime error: Exhausted data descriptors in format
> ()
>
> I think it is standard-conforming in both cases. Intel Fortran behaves
> similarly. Since the format string "()" is currently not legal if
> there are items in the output list, redefining it so that
>
> write (*,"()") a,b,c
>
> is the same as
>
> write (*,*) a,b,c
>
> would not break any currently standard Fortran code, and it would
> bring into conformance some code that used the vendor extension. Since
> some vendors have already done it, it is obviously doable. Therefore
> my revised suggestion is for a "()" format to mean the same as *.- Tekst u=
it oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

I like the idea, but would list-directed input/output not be
implemented completely differently than formatted input/output?

If that is true, then supporting dynamic format strings in this
way would require doubly implementing the read or write
statement.

Regards,

Arjen

garylscott@sbcglobal.net

2008-01-25, 7:21 pm

On Jan 25, 7:38=A0am, Beliavsky <beliav...@aol.com> wrote:
> On Jan 25, 7:13=A0am, "David Jones" <dajx...@ceh.ac.uk> wrote:
>
>
>
>
>
[color=darkred]
>
>
>
>
>
>
m[color=darkred]
>
>
ct desired.[color=darkred]
>
> G95 allows
>
> write (*,"()")
>
> giving a blank line but not
>
> write (*,"()") 2
>
> giving the error message
>
> Fortran runtime error: Exhausted data descriptors in format
> ()
>
> I think it is standard-conforming in both cases. Intel Fortran behaves
> similarly. Since the format string "()" is currently not legal if
> there are items in the output list, redefining it so that
>
> write (*,"()") a,b,c
>
> is the same as
>
> write (*,*) a,b,c
>
> would not break any currently standard Fortran code, and it would
> bring into conformance some code that used the vendor extension. Since
> some vendors have already done it, it is obviously doable. Therefore
> my revised suggestion is for a "()" format to mean the same as *.- Hide qu=
oted text -
>
> - Show quoted text -

Would much prefer "write(*,'(*)')"

An empty list is simply "unspecified" to me. That is the most clear
meaning of '()' (i.e. programmer forgot to specify something, an
error). '(*)' implies "wild card" or "free format" to me. I really
really hate empty meaning "free format".

Gordon Sande

2008-01-25, 7:21 pm

On 2008-01-25 10:28:58 -0400, Arjen Markus <arjen.markus@wldelft.nl> said:

> On 25 jan, 14:38, Beliavsky <beliav...@aol.com> wrote:
>
> m
> ct desired.
> it oorspronkelijk bericht niet weergeven -
>
> I like the idea, but would list-directed input/output not be
> implemented completely differently than formatted input/output?
>
> If that is true, then supporting dynamic format strings in this
> way would require doubly implementing the read or write
> statement.
>
> Regards,
>
> Arjen

There often are two versions of formatted output. In one the format
is static and is precompiled into many calls and other logic. In the
other the format is only known as a character string at run time and
has to be dynamically decoded into many calls and other logic. Sometimes
only the second is present as the first is just an efficiency short cut.
It can provide much better diagnostics, and often at compile time, so
can be very helpful.

I find the equivalence of write ( *, * ) and write ( *, '(*)' )
somewhat more convincing as it represents a positive assertion on
the part of the programmer. I find a format of '()' to be too close
to a programming error for comfort.

Richard Maine

2008-01-25, 7:21 pm

Arjen Markus <arjen.markus@wldelft.nl> wrote:

> I like the idea, but would list-directed input/output not be
> implemented completely differently than formatted input/output?
>
Just my usual kneee-jerk here. List directed I/O is formatted I/O. The
contrast you mean is between list-directed and explicit formatting.

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

glen herrmannsfeldt

2008-01-25, 7:21 pm

garylscott@sbcglobal.net wrote:
(snip)

> Would much prefer "write(*,'(*)')"

> An empty list is simply "unspecified" to me. That is the most clear
> meaning of '()' (i.e. programmer forgot to specify something, an
> error). '(*)' implies "wild card" or "free format" to me. I really
> really hate empty meaning "free format".

I believe an empty FORMAT list was not legal for Fortran 66, but
it looks like it is for Fortran 2003. It would not work very well
with list items, as you say, but otherwise it doesn't seem illegal.

How about :

write(*,'()') (x(i),i=1,n)

when n is zero? That has an I/O list, but writes zero items.

-- glen

glen herrmannsfeldt

2008-01-25, 7:21 pm

Richard Maine wrote:

> Just my usual kneee-jerk here. List directed I/O is formatted I/O. The
> contrast you mean is between list-directed and explicit formatting.

I have a WATFIV manual from September 1970, partly based on
a U of Waterloo manual from September 1969.

WATFIV has CHARACTER variables, internal I/O, format-free I/O, and
expressions in I/O (well, O) lists. Probably my four favorite
Fortran 77 features already available in 1969.

format-free seems to be the term they use for what is now
list directed I/O, the latter name as far as I know
borrowed from PL/I.

-- glen

Richard Maine

2008-01-25, 7:21 pm

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

> I believe an empty FORMAT list was not legal for Fortran 66, but
> it looks like it is for Fortran 2003. It would not work very well
> with list items, as you say, but otherwise it doesn't seem illegal.
>
> How about :
>
> write(*,'()') (x(i),i=1,n)
>
> when n is zero? That has an I/O list, but writes zero items.

The wording of the f2003 standard seems pretty explicit on this. But
just to make sure, the standard even has a note (Note 10.4 in f2003)
that explicitly addresses that exact question.

The wording in question is

"If an input/output list specifies at least one effective list item,
at least one data edit descriptor shall; exist in the format
specification."

The important word here is "effective". The term "effective list item"
is carefully defined in the standard. The above example has an I/O list,
but it has no efffective list items.

Note 10.4

"An empty format specification of the form () may be used only
if the input/output list has no efffective list items (9.5.3.4). Zero
length character items are effective list items, but zero sized
arrays and implied DO lists with an iteration count of zero are not."

Thus the above example is fine (as long as n is zero). It seems on the
surface like a slightly odd thing to do, but I could see something
comparable happening if the format were a character variable rather than
a literal string. The variable value might be built up dynamically and
end up empty of n were zero.

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

Sponsored Links