For Programmers: Free Programming Magazines  


Home > Archive > Fortran > December 2006 > printing in fortran









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 printing in fortran
lane straatman

2006-12-11, 7:12 pm

I'm working through the exercises in MRC and find myself hamhanded with
output. I tried to search using google, but that gave me results from
every newsgroup, and so was guaranteed to be drowned out by
irrelevance.

Q1) In C, printf does not advance the line without the "\n" in the
specification. How does one print or write in fortran without
advancing the line?

Q2) In C, one has stdout, stdin, and stderr defined. Does fortran have
an analog?

Q3) I've only thumbed through the section on interoperability with C;
could a guy use a properly-interfaced call to printf ?

Grateful for any help, LS

Joost

2006-12-11, 7:12 pm

> Q1) In C, printf does not advance the line without the "\n" in the
> specification. How does one print or write in fortran without
> advancing the line?


write(6,'(A)',ADVANCE="NO") "Hi..."

>
> Q2) In C, one has stdout, stdin, and stderr defined. Does fortran have
> an analog?


nothing standard but typically unit 6,5 and 0 respectively

write(6,*) "Hi"
read(5,*) N
write(0,*) "Error"

> Q3) I've only thumbed through the section on interoperability with C;
> could a guy use a properly-interfaced call to printf ?


mixing Fortran/C IO is not a very good idea, and I don't think there is
a way to interface to variadic functions (like printf).

Joost

Richard E Maine

2006-12-11, 7:12 pm

lane straatman <grumpy196884@netzero.net> wrote:

> Q1) In C, printf does not advance the line without the "\n" in the
> specification. How does one print or write in fortran without
> advancing the line?


Most commonly, one doesn't. You output things line-at-a-time instead of
single item at a time. That works fine for the huge majority of the
cases. It is usually more a matter of getting used to the different way
of doing things than that there is a real need to do otherwise. That's
why you won't see it highlighted in most texts - it isn't the most usual
way to do things in Fortran. The number of times the question comes up
here is disproportionate (people ask when they have problems, rather
than when they don't).

That being said....

When you do want to do it, that's what advance='no' in a write statement
does.

> Q2) In C, one has stdout, stdin, and stderr defined. Does fortran have
> an analog?


Yes. The two * units correspond directly to stdin and stdout. They are a
little awkward in some situations because * is a piece of syntax that
must be hard-wired into the code instead of a value, which can be
dynamically set. Essentially all compilers also have unit numbers that
correspond to stdin and stdout (and often stderr). The exact unit
numbers are compiler dependent. By far the most common values in today's
compilers are 5 for stdin and 6 for stdout. I advise using variables or
named constants for these. That way, you isolate the needed change to a
single line in the whole program if you ever more to a compiler that
uses a different number. That is, do

write(stdout, ...

where stdout (or any other name of your choosing) is a variable or named
constant with the value 6. Don't do

write(6, ...

In f2003, the module parameters INPUT_UNIT, OUTPUT_UNIT, and ERROR_UNIT
are a portable wayto get at the right numbers.

> Q3) I've only thumbed through the section on interoperability with C;
> could a guy use a properly-interfaced call to printf ?


Can't be done with the standard f2003 stuff. Printf has a variable
number of arguments. That specifically is one of the feature that is not
supported by the F2003 interop stuff.

Also, be aware of the fine print relating to I/O and C interop. All bets
are off if you use both C and Fortran to do I/O on the same file during
a single OPEN. Might work. Might not. Might do "odd" things like doing
the I/O in a non-obvious order (for example, if there is buferring going
on). So I advise against jumping back and forth willy nilly. If you open
a file in C, do the I/O to it only in C. If you open a file in Fortran,
do the I/O only in Fortran.

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

2006-12-11, 7:12 pm


Richard E Maine wrote:
> lane straatman <grumpy196884@netzero.net> wrote:
>
>
> Most commonly, one doesn't. You output things line-at-a-time instead of
> single item at a time. That works fine for the huge majority of the
> cases. It is usually more a matter of getting used to the different way
> of doing things than that there is a real need to do otherwise. That's
> why you won't see it highlighted in most texts - it isn't the most usual
> way to do things in Fortran. The number of times the question comes up
> here is disproportionate (people ask when they have problems, rather
> than when they don't).
>
> That being said....
>
> When you do want to do it, that's what advance='no' in a write statement
> does.
>
>
> Yes. The two * units correspond directly to stdin and stdout. They are a
> little awkward in some situations because * is a piece of syntax that
> must be hard-wired into the code instead of a value, which can be
> dynamically set. Essentially all compilers also have unit numbers that
> correspond to stdin and stdout (and often stderr). The exact unit
> numbers are compiler dependent. By far the most common values in today's
> compilers are 5 for stdin and 6 for stdout. I advise using variables or
> named constants for these. That way, you isolate the needed change to a
> single line in the whole program if you ever more to a compiler that
> uses a different number. That is, do
>
> write(stdout, ...
>
> where stdout (or any other name of your choosing) is a variable or named
> constant with the value 6. Don't do
>
> write(6, ...
>
> In f2003, the module parameters INPUT_UNIT, OUTPUT_UNIT, and ERROR_UNIT
> are a portable wayto get at the right numbers.
>
>
> Can't be done with the standard f2003 stuff. Printf has a variable
> number of arguments. That specifically is one of the feature that is not
> supported by the F2003 interop stuff.
>
> Also, be aware of the fine print relating to I/O and C interop. All bets
> are off if you use both C and Fortran to do I/O on the same file during
> a single OPEN. Might work. Might not. Might do "odd" things like doing
> the I/O in a non-obvious order (for example, if there is buferring going
> on). So I advise against jumping back and forth willy nilly. If you open
> a file in C, do the I/O to it only in C. If you open a file in Fortran,
> do the I/O only in Fortran.

Thanks both for replies. I was just hoping to to use printf as a way
to figure out the gotchas of interop, and we appear to have one from
the get-go. Working through the exercises has been profitable. I
don't see any reason that I wouldn't want to complete them, with the
exception of the pointers stuff.

Has anyone talked about having a FAQ list for this forum?

LS

glen herrmannsfeldt

2006-12-11, 7:12 pm

lane straatman <grumpy196884@netzero.net> wrote:
(snip regarding Fortran and C I/O and interoperability)

> Thanks both for replies. I was just hoping to to use printf as a way
> to figure out the gotchas of interop, and we appear to have one from
> the get-go. Working through the exercises has been profitable. I
> don't see any reason that I wouldn't want to complete them, with the
> exception of the pointers stuff.


There is vfprintf(), if not standard it exists in most implementations.
Instead of a variable number of arguments it takes an array of pointers
to the list items.

I believe that in many implementations the Fortran library uses
the C library to do the actual I/O, so mixing C and Fortran I/O
has a reasonable chance of working, though it might be that Fortran
buffers it some before passing it on.

-- glen
Richard Maine

2006-12-11, 7:12 pm

lane straatman <grumpy196884@netzero.net> wrote:

> Has anyone talked about having a FAQ list for this forum?


Many times. Perhaps it will happen someday. But...

Its just a lot of work maintaining a good one. There are some FAQ lists
running around and occasionally posted, but they tend to be on
higher-level questions such as what books and compilers are available. I
haven't seen a FAQ on this kind of question - the "how do you do this in
Fortran?" stuff. I agree it would be worthwhile. Its just a lot of work
to do a good job (and maintain it).... and not so valuable to do one
that's not so good.

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

2006-12-11, 7:12 pm

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

> I believe that in many implementations the Fortran library uses
> the C library to do the actual I/O, so mixing C and Fortran I/O
> has a reasonable chance of working, though it might be that Fortran
> buffers it some before passing it on.


And that bufferring can cause a mess. I'll stick with my:

> Might work. Might not. Might do "odd" things like doing
> the I/O in a non-obvious order


The "non-obvious order" bit refers to buferring effects.

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

2006-12-11, 7:12 pm

On 8 Dec 2006 12:33:08 -0800, lane straatman <grumpy196884@netzero.net>
wrote in <1165609988.396061.17730@f1g2000cwa.googlegroups.com>:

> Has anyone talked about having a FAQ list for this forum?


Many times. So far we've all been too busy, or unwilling to stick
our necks out... Thanks to a regular there is now a reasonable
description of Fortan on the wikipedia; that may be a place to do such a
thing (I'd be more willing to do a single piece on internal read/writes
[*THE* most FAQ] than something encompassing each and every query that pops
up often enough).

--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Gary Scott

2006-12-11, 7:12 pm

lane straatman wrote:
> Richard E Maine wrote:
>
>
> Thanks both for replies. I was just hoping to to use printf as a way
> to figure out the gotchas of interop, and we appear to have one from
> the get-go. Working through the exercises has been profitable. I
> don't see any reason that I wouldn't want to complete them, with the
> exception of the pointers stuff.
>
> Has anyone talked about having a FAQ list for this forum?
>


Yes, there have been various faq-like documents and web sites. One is
http://www.fortran.com where the most faq-like file is posted. I used
to have fortranfaq.com but never finished it. I have
http://www.fortranlib.com which has a lot of general stuff but not much
on programming itself. Since I've been unable to keep it up to date,
most of the content of fortranlib.com has been ported or duplicated to
http://www.dmoz.com/Computers/Progr...guages/Fortran/

I had worked on setting up a wikipedia-like replacement for
fortranlib.com, but as soon as I had it up and running, a hacker blasted
it and I didn't have time to recover before my next class started. I
actually spent quite a bit of money and time setting up nifty database
stuff for it. Probably wouldn't take much work.

If I ever finish my master's degree...if somebody want so volunteer to help.

> LS
>



--

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

2006-12-11, 7:12 pm


Gary Scott wrote:
> lane straatman wrote:
[color=darkred]
Would Cbfalconer's ggets be a good candidate?
/* File ggets.h - goodgets is a safe alternative to gets */
/* By C.B. Falconer. Public domain 2002-06-22 */
/* attribution appreciated. */


/* Revised 2002-06-26 New prototype.
2002-06-27 Incomplete final lines
*/

/* fggets and ggets [which is fggets(ln, stdin)] set *ln to
a buffer filled with the next complete line from the text
stream f. The storage has been allocated within fggets,
and is normally reduced to be an exact fit. The trailing
\n has been removed, so the resultant line is ready for
dumping with puts. The buffer will be as large as is
required to hold the complete line.

Note: this means a final file line without a \n terminator
has an effective \n appended, as EOF occurs within the read.

If no error occurs fggets returns 0. If an EOF occurs on
the input file, EOF is returned. For memory allocation
errors some positive value is returned. In this case *ln
may point to a partial line. For other errors memory is
freed and *ln is set to NULL.

Freeing of assigned storage is the callers responsibility
*/

#ifndef ggets_h_
# define ggets_h_

# ifdef __cplusplus
extern "C" {
# endif

int fggets(char* *ln, FILE *f);

#define ggets(ln) fggets(ln, stdin)

# ifdef __cplusplus
}
# endif
#endif
/* END ggets.h */
He has claimed that the all the linking information is properly in the
header file, and he seems like the type that would follow his own
advice, although a cplusplus wrapper wouldn't really seem to matter
over here. A good reason to use this function is that he has a grab
bag of other files to test this with (at his site).
[color=darkred]
> [Mr. Scott's last sentences on FAQ:]
> Yes, there have been various faq-like documents and web sites. One is
> http://www.fortran.com where the most faq-like file is posted. I used
> to have fortranfaq.com but never finished it. I have
> http://www.fortranlib.com which has a lot of general stuff but not much
> on programming itself. Since I've been unable to keep it up to date,
> most of the content of fortranlib.com has been ported or duplicated to
> http://www.dmoz.com/Computers/Progr...guages/Fortran/


> If I ever finish my master's degree...if somebody want so volunteer to help.

I'd need a baud rate that is faster than I can clap to commit to it.
LS

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

I tell people that fortran is sexy.

lane straatman

2006-12-13, 4:19 pm


Joost wrote:
>
> write(6,'(A)',ADVANCE="NO") "Hi..."

6 would seem to work for me. I find myself thinking "where is this
specified in the header files?" I tried to find INPUT_TYPE somewhere
in silverfrost without success.

This compiles and behaves. Before I hook up bells and whistles and a
lot more logic, I want to figure out, say, how likely the event is that
there would be exactly two pocket pairs in eight hand play, a priori
and empirically. For a display, I'm fishing for good ideas. I was
thinking of a char array whose biggest field contains 'Queen of
Spades'--looks like fifteen chars, and use the ordering from bridge.
'Queen of Spades' would be in the 50th field.
Q4) Do " " and ' ' do the same thing when enclosing string literals?

LS
program poker4
IMPLICIT NONE
integer, dimension(52) :: cards

call random_seed()
call shuffle(cards)
call deal(cards)
WRITE(*,*) cards
contains

subroutine shuffle(cards)
integer :: cards(:), ii, index
real :: numbers(size(cards))
call random_number(numbers)
do ii = 1, size(cards)
index = minloc(numbers, dim=1)
cards(ii) = index
numbers(index) = 2.0
end do
end subroutine shuffle

subroutine deal(cards)
integer :: cards(:), players, j ,i, hold
players = 8
hold = 2*players
do i = 1, hold , 2
do j = 0 , 1
write(*,'(i5, i5)',ADVANCE='NO') (i+j), cards(i+j)
end do
write(6,'(A)',ADVANCE='YES')
end do
write(*,'(a, i5, i5, i5)') "flop: ", cards(hold+1), cards(hold+2),
cards(hold+3)
write(*,'(a, i5)') "turn: ", cards(hold+4)
write(*,'(a, i5)')"river: ", cards(hold+5)
end subroutine deal

end program

robin

2006-12-15, 7:06 pm

Joost wrote in message <1165529490.880487.245440@f1g2000cwa.googlegroups.com>...
>
>write(6,'(A)',ADVANCE="NO") "Hi..."
>
>
>nothing standard but typically unit 6,5 and 0 respectively


Not that at all.

PRINT *, x
and WRITE(*,*) x
are sufficient.

>write(6,*) "Hi"
>read(5,*) N
>write(0,*) "Error"



Dave Thompson

2006-12-26, 7:10 pm

On Fri, 8 Dec 2006 21:03:45 +0000 (UTC), glen herrmannsfeldt
<gah@seniti.ugcs.caltech.edu> wrote:

> lane straatman <grumpy196884@netzero.net> wrote:
> (snip regarding Fortran and C I/O and interoperability)
>
>
> There is vfprintf(), if not standard it exists in most implementations.
> Instead of a variable number of arguments it takes an array of pointers
> to the list items.
>

vprintf (to stdout), vfprintf, and vsprintf (to string) are standard
since C89, and vsnprintf in C99. But they (and other v* routines) do
NOT take an array of pointers; they take a 'va_list' which is a type
defined by the C implementation, not required to be and usually not
documented, which allows _access_ to a (C) caller's vararg list. This
is usually just a single pointer, or a pointer plus some status bits.
There isn't, even in F03 AIUI, a portable Ftn way to create such.


- David.Thompson1 at worldnet.att.net
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com