advance='no'

advance='no'

Bild des Benutzers sandwich

using

>> write (*,'(a)',advance='no') "x = "
>> read *, x

doesn't work: no text appears on the screen before enter/return is pressed.


>> write (*,'(a)',advance='no') "x = "
>> close (6)
>> read *, x

works correctly, but then there will be no more output on the screen (print *, ... ; write (*,*) ...) for the rest of the program.


any idea? thanks!

p.s.: i use "Fortran Compiler for 32-bit applications, Version 7.0 Build 20030129Z" on linux redhat 8.0

22 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers Steve Lionel (Intel)

Try a current 7.1 compiler. The behavior you're seeing is standard-conforming, but not very popular. I think this was changed for 7.1.

Steve

Steve
Bild des Benutzers sandwich

yes it works quite well! (both with and without 'close')
thanx!

Bild des Benutzers sandwich

another problem exists in connection with the T-format:

>> write (*,'(t30,a,t20,a,t10,a)') "30", "20", "10"

produces

>> _________10________20________30

but

>> write (*,'(t30,a,)',advance='no') "30"
>> write (*,'(t20,a,)',advance='no') "20"
>> write (*,'(t10,a,)')_____________ "10"

results in

>> _____________________________30___________________20 __________10

so the position counting starts after the end of the last writing (though "advance='no'"). even with the TL format one cannot go before this point.

any idea?

(p.s.: i use "_" instead of blanks, because more blanks will only be shown as one.)

Bild des Benutzers Steve Lionel (Intel)

I had to stare at the standard for a while to make sure I understood what should happen. I agree with you that ifc 7.1 gets it wrong. The next major release, due towards the end of this year, will get it right (the I/O libraries come from CVF and they do it right.)

Steve

Steve
Bild des Benutzers sandwich

all right, i'll wait for that.

thank you!

Bild des Benutzers hirchert728

Steve said he agreed that ifc 7.1 is getting this wrong. When I read the standard, it appears to me that ifc 7.1 is getting it right. The standard says:

The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur at the nth character position of the record, relative to the left tab limit.

This appears to me to be what ifc is doing. The first nonadvancing write tabs to column 30 and puts out "30". At the beginning of the next write, the left tab limit is set to the current position in the record (i.e., column 32) and it tabs to the 20th column relative to that (i.e., column 51 in absolute terms) and put out "20". Similarly, the third write sets the left tab limit to the current posiont (now column 53), tabs to column 10 relative to that (in absolute terms, column 62), puts out "10" and ends the records. This appears to be what ifc is doing. What do you think should be the output of these statements?

Bild des Benutzers sandwich

maybe the behaviour is standard-conform, i don't know.

i would like to get the same output as in the first example, say as long as the record (if this is the right meaning of record) is not closed ("advance='no'" should keep it open) i would like to be able to reach every position within this record (line), that means also to be able to go to a position before the last written one.

maybe the standard does not allow that, but i would like to have such a possibility, especially for a running counter, e.g.:

do i=1,n
__... ! do something w/o printing/writing on the screen
__write (*,'(t1,i6)',advance='no') i
end do



Bild des Benutzers Steve Lionel (Intel)

Interesting. I had apparently entirely missed the part about "left tab limit". It could indeed be that ifc has the correct behavior here - we'll investigate.

Steve

Steve
Bild des Benutzers Steve Lionel (Intel)

Upon further investigation, my initial response was incorrect. This is a bug and I have reported it to engineering.

Steve

Steve
Bild des Benutzers sandwich

after so many responses:

1. what was your "initial response"?
2. what is the bug now? ("this is a bug")

Bild des Benutzers Steve Lionel (Intel)

My initial response was that CVF was correct and ifc was wrong. My reconsidered response was that CVF was wrong and ifc was correct. Unfortunately, there's a real possibility that the next Intel Fortran for Linux will pick up the bad CVF behavior unless the bug gets fixed in time for the release. I have submitted it to the engineers as a bug report.

Steve

Steve
Bild des Benutzers sandwich

so it is the bad/uncorrect behaviour that i would like to have (running counter, reaching any position within the topical line)?
wouldn't this be a more flexibel behaviour?

Bild des Benutzers finneyb

I have the same problem with advance="no". I have loaded the currently available version. Advance="no" does not appear to flush the output buffer to produce any screen output. Short of an close/open sequence, can you think of any other workaround?

Bild des Benutzers Steve Lionel (Intel)

Sandwich - while it may seem more flexible, it's not what the standard says and can cause problems with implementations that want to flush the partial line. It assumes that you can reliably reposition in a partial record that was already written.

Finneyb, you may have an old version of Intel Fortran - try getting the latest update.

Steve

Steve
Bild des Benutzers finneyb

No, as I stated, I have the most current version available.

Bild des Benutzers finneyb

Well, I THOUGHT I had the most recent version (I had 7.1.008). 7.1.030 did the trick. Thanks Steve.

Bild des Benutzers sandwich

well, steve, the standard is the chief, isn't it?
thanks,
sandwich

p.s.: how can a simple user make suggestions to the standard makers?

Bild des Benutzers Steve Lionel (Intel)

You could contact a committee member and make your suggestion, but if you want to suggest changing this behavior, it will never fly, as it would break existing, standard-conforming code.

Steve

Steve
Bild des Benutzers sandwich

as i have some other ideas, could you please give me some e-mail adresses of committee members?

Bild des Benutzers Steve Lionel (Intel)

Sorry, that's not for me to do.

Let me suggest that the comp.lang.fortran newsgroup is a good place to start a discussion of such things. Several members of the committee follow it and may respond.

Steve

Steve
Bild des Benutzers sandwich

o.k. thanx.

sandwich

Melden Sie sich an, um einen Kommentar zu hinterlassen.