Home > Archive > Fortran > November 2005 > WRITE + new line
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]
|
|
| Martin Glaser 2005-11-14, 7:01 pm |
| Hi,
I want to write an 2-dimensional array to a textfile, but WRITE always
uses a new line. How can you stop that?
I use something like this:
DO i=1, length1
DO j=1, length2
WRITE(*,*) array(i,j)
END DO
END DO
I read that it shout be able to do something like this:
DO i=1, length1
WRITE(*,*) (array(i,j), j=1, length2)
END DO
but it still uses a new line for each entry.
Is there a convenient standard Fortran 90/95 way to do this?
Thanks,
Martin
| |
| Dan Nagle 2005-11-14, 7:01 pm |
| Hello,
One issue is that list directed format (the second * below)
allows the processor to create new lines at will. If you want
to control the format more precisely, you must write your own
format string.
Also investigate the recl= on the open statement to ensure
your processor allows records long enough for your intended
use.
HTH
Martin Glaser wrote:
> Hi,
>
> I want to write an 2-dimensional array to a textfile, but WRITE always
> uses a new line. How can you stop that?
> I use something like this:
> DO i=1, length1
> DO j=1, length2
> WRITE(*,*) array(i,j)
> END DO
> END DO
>
> I read that it shout be able to do something like this:
> DO i=1, length1
> WRITE(*,*) (array(i,j), j=1, length2)
> END DO
> but it still uses a new line for each entry.
>
> Is there a convenient standard Fortran 90/95 way to do this?
>
> Thanks,
> Martin
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Martin Glaser 2005-11-14, 7:01 pm |
| Dan Nagle schrieb:
> Hello,
>
> One issue is that list directed format (the second * below)
> allows the processor to create new lines at will. If you want
> to control the format more precisely, you must write your own
> format string.
>
> Also investigate the recl= on the open statement to ensure
> your processor allows records long enough for your intended
> use.
>
> HTH
>
> Martin Glaser wrote:
>
>
>
>
Thank you for your answer.
What would an appropriate format string be? Just using Write(*, '(I8)')
array(i,j) doesn't work because it still makes a new line.
Hope somebody can help me,
martin
| |
| Michael Prager 2005-11-14, 7:01 pm |
| Martin Glaser <ska1do@web.de> wrote:
>Hi,
>
>I want to write an 2-dimensional array to a textfile, but WRITE always
>uses a new line. How can you stop that?
As Dan Nagle said, using list directed output (FMT=*) allows the
compiler to format the output as it wishes. You need to write
FORMAT statements if YOU want to specify the output format.
Also as Dan said, you can generally set the RECL= specifier of
the OPEN statement to make sure the line length is sufficient
for what you want to do. This is compiler-dependent but often
needed for long lines written to a text file.
Two new commentss:
1. Examine the ADVANCE= specifier of the WRITE statement. It
is designed to allow subsequent WRITE statements to write data
to the same line (i.e., without a new line).
2. Also examine the "implied DO loop" that can form part of a
WRITE statement. It may simplify your code in this application.
Any Fortran book or tutorial will have Information on all of the
above.
Hope that helps.
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
| |
| Richard E Maine 2005-11-14, 7:01 pm |
| Martin Glaser <ska1do@web.de> wrote:
> What would an appropriate format string be? Just using Write(*, '(I8)')
> array(i,j) doesn't work because it still makes a new line.
That's because your format tells it to do so; you've got just a single
data item and a single edit descriptor I8.
By far the simplest way to do this is to specify a large number of
repetitions of the edit descriptor. If you run out of data before you
run out of the number of specified repetitions, it will just finish the
line there, which is what you want. You want something like
write (*,'(999i8)') array(i,:)
You can use an implied DO if you want instead of the array slice
notation, but the slice notation is simpler (assuming you have an f90 or
better compiler). But in any case, you *MUST* do one of 2 things -
either:
1. Write out a whole row of the array in a single write statement.
or
2. Use non-advancing I/O.
I'll let others show the nonadvancing I/O way. It also works. But if you
don't use non-advancing I/O, then you are going to get a new line after
each write statement, so you have to put everything that you want to go
on one line in a single write statement.
--
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
| |
| James Van Buskirk 2005-11-14, 7:01 pm |
| "Richard E Maine" <nospam@see.signature> wrote in message
news:1h60kqm.1f0qbvb1slsw5cN%nospam@see.signature...
> I'll let others show the nonadvancing I/O way.
program new_line
implicit none
integer length1, length2
integer :: array(2,3) = reshape((/ &
1, 2, 3, &
4, 5, 6 /), &
shape = shape(array), order = (/2,1/))
character(80) fmt
character(80) temp
integer i, j
length1 = size(array,1)
length2 = size(array,2)
write(*,'(a)') ' Non-advancing I/O way:'
do i = 1, length1
do j = 1, length2
write(temp,*) array(i,j)
write(*,'(1x,a)',advance='no') trim(adjustl(temp))
end do
write(*,'()')
end do
write(*,'()')
write(*,'(a)') ' Variable format way'
write(fmt,'(a,i0,a)') '(',length2,'(1x,i8))'
write(*,fmt) transpose(array)
end program new_line
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Dan Nagle 2005-11-14, 7:01 pm |
| Martin Glaser wrote:
<snip>
<snip>
[color=darkred]
> Thank you for your answer.
> What would an appropriate format string be? Just using Write(*, '(I8)')
> array(i,j) doesn't work because it still makes a new line.
Well, you probably know how large array is, so write
a format like 999i8, or whatever value you need
in place of the 999. The best value is the leading
extent of array.
HTH
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| Martin Glaser wrote in message <1131989486.54893@news.liwest.at>...
>Hi,
>
>I want to write an 2-dimensional array to a textfile, but WRITE always
>uses a new line. How can you stop that?
>I use something like this:
>DO i=1, length1
> DO j=1, length2
> WRITE(*,*) array(i,j)
> END DO
>END DO
>
>I read that it shout be able to do something like this:
>DO i=1, length1
> WRITE(*,*) (array(i,j), j=1, length2)
>END DO
>but it still uses a new line for each entry.
This should start a new line for each row.
>Is there a convenient standard Fortran 90/95 way to do this?
Print *, array
>Thanks,
> Martin
| |
| Dan Nagle 2005-11-15, 7:01 pm |
| Hello,
robin wrote:
> Martin Glaser wrote in message <1131989486.54893@news.liwest.at>...
<snip>
>
> This should start a new line for each row.
Actually, no. List-directed formatting, as indicated
by the second * in the write statement, allows the processor
to start new lines at will. Richard has explained this
very well earlier in this thread.
Please read the section (I'll not find this one for you)
on list-directed output in the Fortran standard.
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Rich Townsend 2005-11-15, 7:01 pm |
| robin wrote:
> Martin Glaser wrote in message <1131989486.54893@news.liwest.at>...
>
>
> This should start a new line for each row.
The runtime is also free to insert a new line in the middle of each row.
>
>
>
>
> Print *, array
>
No, the runtime is still free to insert new lines in the middle of the array
elements.
Where you're going wrong is the list-directed format *, which permits the
runtime to insert new lines wherever it likes. See Richard Maine's post for a
demonstration of how to avoid this.
cheers,
Rich
| |
| glen herrmannsfeldt 2005-11-15, 7:01 pm |
| Dan Nagle wrote:
(snip)
(snip)
[color=darkred]
[color=darkred]
> Actually, no. List-directed formatting, as indicated
> by the second * in the write statement, allows the processor
> to start new lines at will. Richard has explained this
> very well earlier in this thread.
It should still start a new line for each row. It may start a new line
in other places, too. I would be pretty surprised if it started a new
line for each element, though maybe for COMPLEX*32 I wouldn't be so
surprised. In any case, yes, it is allowed to do that.
-- glen
| |
| Dan Nagle 2005-11-15, 7:01 pm |
| Hello,
glen herrmannsfeldt wrote:
> Dan Nagle wrote:
<snip>
>
>
> It should still start a new line for each row.
I don't see, off hand, where in 10.9.2 this is required.
I may have missed it, I suppose, but it's not that large a section.
Most of the discussion there concerns allowed formats and separators.
Usually, transfers are processed in term of effective list items.
In this case, the effective list item is the array element, IIRC.
And I admit I haven't checked a lot of compiler to see
what the usual practice is.
> It may start a new line
> in other places, too. I would be pretty surprised if it started a new
> line for each element, though maybe for COMPLEX*32 I wouldn't be so
> surprised. In any case, yes, it is allowed to do that.
Well, OK, but the OP asked
[color=darkred]
> Martin Glaser wrote:
>
which I take to mean that he has too many new lines,
not a shortage.
In any case, Robin's answer was, at best, incomplete.
Yet it was offered in his usual highly-confident tone.
I still think Richard gave the most complete answer.
And a reading of section 10.9.2 on list-directed output
is the authoritative source.
But sometimes the "standards-hat" is a bit tight, and I try
to provide advice which is highly portable. "Just happening"
to work on one or a few compiler(s) is not always guaranteed
to be helpful with the next compiler.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard E Maine 2005-11-15, 7:01 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> glen herrmannsfeldt wrote:
>
> I don't see, off hand, where in 10.9.2 this is required.
That's because it is the wrong section. I haven't bothered to track down
the exact citation because I'm busy... and frankly it is too elementary
to be worth bothering with.... but you need to be looking in chapter 9 -
not 10. The new line at the beginning of the write statement is
completely independent of format processing; it happens *BEFORE* format
processing starts. This is all about the difference between advancing vs
non-advancing and has nothing to do with list-directed vs explicit
formats.
Probably look in 9.5.3 in the discussion about positioning before data
transfer. Anyway, somewhere in 9 - not 10.
The processor choice in question is for additional newlines during the
data transfer; the initial one is not at the processor's option.
List-directed is the wrong approach for the OP because of the additional
newlines that might be added at the processor's option.
--
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
| |
| Dan Nagle 2005-11-15, 7:01 pm |
| Hello,
Richard E Maine wrote:
<snip>
> The processor choice in question is for additional newlines during the
> data transfer; the initial one is not at the processor's option.
It's not a question of the _initial_ new line,
but of a new line being implied (or not) by a new row
when the array is specified as a whole array.
I can see where (9.5.2) [192:20-22] the whole array
is a sequence of scalar list items in array element order.
I don't see any mention of rank, nor new rows etc.
Most :-) of 9.5.3 speaks to Derived Type I/O. Anyway,
I missed any mention of new rows starting new lines.
> List-directed is the wrong approach for the OP because of the additional
> newlines that might be added at the processor's option.
Agreed.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard E Maine 2005-11-15, 7:01 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> Richard E Maine wrote:
>
>
> It's not a question of the _initial_ new line,
> but of a new line being implied (or not) by a new row
> when the array is specified as a whole array.
Ah. Then context was lost by someone somewhere along the line. For a
whole array, I'd certainly agree. And somewhere in this thread, someone
did show a whole array form. But the code snippet that this claim was
about, copied&pasted directly from your posting on it, was
>
> Actually, no.
That is not a whole array form and, quoting directly from glenn's
followup, which I 100% agree with
> It should still start a new line for each row. It may start a new line
> in other places, too.
--
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
| |
| James Giles 2005-11-15, 7:01 pm |
| Dan Nagle wrote:
....
>
> I don't see, off hand, where in 10.9.2 this is required.
The piece of code to which the phrase "this should start a new line
for each row" originally referred was:
> DO i=1, length1
> WRITE(*,*) (array(i,j), j=1, length2)
> END DO
And, indeed, this should start a new line for each row, since
each row is written by a different pass through the loop, and
so, by a different WRITE.
Now, if the code were:
WRITE(*,*) ((Array(i,j), j=1, length2), i=1,length1)
Here there is no requirement that any new lines be embedded
at all (except at the start of the record).
--
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
| |
| Dan Nagle 2005-11-15, 7:01 pm |
| Hello,
James Giles wrote:
<snip>
> Now, if the code were:
>
> WRITE(*,*) ((Array(i,j), j=1, length2), i=1,length1)
>
> Here there is no requirement that any new lines be embedded
> at all (except at the start of the record).
Agreed. Apparently, I read the post too fast. :-(
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| Dan Nagle wrote in message <1smef.46300$MY4.26907@trnddc03>...
>Hello,
>
>robin wrote:
>
><snip>
>
>
>Actually, no.
Actually, yes, as it has done so for some 40+ years, at least.
> List-directed formatting, as indicated
>by the second * in the write statement, allows the processor
>to start new lines at will.
While a compiler is free to do anything, I doubt that the
writer of a compiler would do anything as stupid as that.
> Richard has explained this
>very well earlier in this thread.
>
>Please read the section (I'll not find this one for you)
>on list-directed output in the Fortran standard.
>--
>Cheers!
>
>Dan Nagle
| |
|
| Rich Townsend wrote in message ...
>robin wrote:
>
>The runtime is also free to insert a new line in the middle of each row.
For a long line, as one expects.
>No, the runtime is still free to insert new lines in the middle of the array
>elements.
No. Typical practice is to start a new line when a line becomes full.
Typically, elements are written out in their entirety, and not broken in mid-element.
>Where you're going wrong is the list-directed format *,
No, I'm not "going wrong".
> which permits the
>runtime to insert new lines wherever it likes.
Once again, while it is up to the compiler to put in new lines as
appropriate (that is, when a line becomes full),
it is NOT normal to have a new line after every element.
> See Richard Maine's post for a
>demonstration of how to avoid this.
>
>cheers,
>
>Rich
| |
| Dan Nagle 2005-11-15, 9:57 pm |
| Hello,
robin wrote:
> Dan Nagle wrote in message <1smef.46300$MY4.26907@trnddc03>...
<snip>
>
>
> Actually, yes, as it has done so for some 40+ years, at least.
I did make a mistake in answering this post too quickly,
but my ill-expressed point was that the processor may add
new lines at will with list directed formatting.
So the new line starting the new row isn't the _only_ new line
present. Sorry, I goofed.
>
>
> While a compiler is free to do anything, I doubt that the
> writer of a compiler would do anything as stupid as that.
Several compilers have default output line length limits
which they, correctly, enforce by starting new lines.
I wouldn't call that stupid. The programmer must try
to get a longer line length by setting recl on the open statement.
Do you really think processors are stupid for not printing,
say, 1e6 numbers on one line?
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Dan Nagle 2005-11-15, 9:57 pm |
| Hello,
robin wrote:
<snip>
> Once again, while it is up to the compiler to put in new lines as
> appropriate (that is, when a line becomes full),
> it is NOT normal to have a new line after every element.
What if my array elements were character*1024 elements?
BTW, what do you mean by "line becomes full"?
Do you mean, the processor-dependent output buffer becomes full?
Please see section 10.9.2 for a discussion of when a processor
may start a new line within an element.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Rich Townsend 2005-11-15, 9:57 pm |
| robin wrote:
> Rich Townsend wrote in message ...
>
>
>
> For a long line, as one expects.
>
>
>
>
> No. Typical practice is to start a new line when a line becomes full.
> Typically, elements are written out in their entirety, and not broken in mid-element.
I used the plural "elements" to indicate between one element and the next. Had I
meant mid-element, I would have written "element", singular.
>
>
>
>
> No, I'm not "going wrong".
>
>
>
>
> Once again, while it is up to the compiler to put in new lines as
> appropriate (that is, when a line becomes full),
> it is NOT normal to have a new line after every element.
Sure, but permissable.
cheers,
Rich
| |
|
| Dan Nagle wrote in message ...
>Hello,
>
>robin wrote:
>
><snip>
>
>
>I did make a mistake in answering this post too quickly,
>but my ill-expressed point was that the processor may add
>new lines at will with list directed formatting.
>So the new line starting the new row isn't the _only_ new line
>present. Sorry, I goofed.
OK. But "at will" tends to be ambiguous; there are specific
times when a new line will be started when the output would exceed
the length of the current line.
>
>Several compilers have default output line length limits
>which they, correctly, enforce by starting new lines.
That's normal.
>I wouldn't call that stupid. The programmer must try
>to get a longer line length by setting recl on the open statement.
>
>Do you really think processors are stupid for not printing,
>say, 1e6 numbers on one line?
There typically are limits on the length of a line for printing,
which the run-time honors by starting a new line when
the current line is filled, or nearly filled.
>--
>Cheers!
>
>Dan Nagle
| |
|
| Rich Townsend wrote in message ...
>robin wrote:
>
>Sure, but permissable.
If it were to occur with typical values, the compiler would be treated as broken.
>cheers,
>
>Rich
|
|
|
|
|