Some newbye questions
Lurkos
I've started to study Fortran 90+ about one week ago and I've found
some things I can't understand well.
Since now I was used to write programs using Matlab scripting languange,
so I almost know the meaning of the most important elements of a
programming language.
Below I've written my doubts. I only want to understand how Fortran
works, then excuse me for possible errors and/or "stange" questions.
(1)
If I have understood well, there is the need to specify the type of the
output of a function both in the function itself and in the "main"
program.
Let's see this example.
PROGRAM main
IMPLICIT NONE
REAL :: functiontest !<--- 1st declaration
REAL :: number
REAL :: value = 100
number = functiontest(value)
END PROGRAM main
FUNCTION functiontest(argument)
IMPLICIT NONE
REAL :: functiontest !<--- 2nd declaration
REAL, INTENT(IN) :: argument
functiontest = argument * 2
END FUNCTION functiontest
Why have I to specify twice the type of the output of a function?
Is it possible to avoid this double declaration? I'm afraid to double
the probability of a mistake.
(1-bis)
If I've understood well, is it possible to encapsulate a function or a
procedure inside of a module.
In this case there isn't the need to declare the kind of output of the
function twice, but an additional USE statement should be used.
According to Chapman, it seems that it's better to encapsulate every
function inside a module, to increare the probability to catch coding
errors with the compiler.
Is it always true? It seems a redundant form of coding.
(2)
Some manuals says that LOGICAL variables occupies 4 bytes.
Why? I would suppose that 1 bit was enough to contain a single bit
information, like true/false (1/0).
--
Lurkos
Jason Blevins
> (1)
> If I have understood well, there is the need to specify the type of the
> output of a function both in the function itself and in the "main"
> program.
> Let's see this example.
>
> PROGRAM main
> IMPLICIT NONE
> REAL :: functiontest !<--- 1st declaration
> REAL :: number
> REAL :: value = 100
>
> number = functiontest(value)
>
> END PROGRAM main
>
> FUNCTION functiontest(argument)
> IMPLICIT NONE
> REAL :: functiontest !<--- 2nd declaration
> REAL, INTENT(IN) :: argument
>
> functiontest = argument * 2
>
> END FUNCTION functiontest
>
> Why have I to specify twice the type of the output of a function?
> Is it possible to avoid this double declaration? I'm afraid to double
> the probability of a mistake.
The recommended solution is, as you mention below, to include your
function in a module which ensures it has an explicit interface.
> (1-bis)
> If I've understood well, is it possible to encapsulate a function or a
> procedure inside of a module.
> In this case there isn't the need to declare the kind of output of the
> function twice, but an additional USE statement should be used.
> According to Chapman, it seems that it's better to encapsulate every
> function inside a module, to increare the probability to catch coding
> errors with the compiler.
> Is it always true? It seems a redundant form of coding.
It's not _that_ redundant. You don't have to create a separate module
for each procedure. You can put all of your procedures in a single
module if you wish, or what's probably better practice, is to group them
by category. You can, for example, place a derived type and all of the
procedures which operate on it in a single module, or place all of your
statistics routines in a single module.
For small programs, another reasonable option is to use internal
procedures, which also have explicit interfaces. Rewriting your
program from above, using an internal procedure:
PROGRAM main
IMPLICIT NONE
REAL :: number
REAL :: value = 100
number = functiontest(value)
CONTAINS
FUNCTION functiontest(argument)
IMPLICIT NONE
REAL :: functiontest
REAL, INTENT(IN) :: argument
functiontest = argument * 2
END FUNCTION functiontest
END PROGRAM main
--
Jason Blevins
Ph.D. Candidate, Department of Economics, Duke University
http://jblevins.org/
Richard Maine
> If I have understood well, there is the need to specify the type of the
> output of a function both in the function itself and in the "main"
> program.
>...
> Why have I to specify twice the type of the output of a function?
> Is it possible to avoid this double declaration? I'm afraid to double
> the probability of a mistake.
Yes, I (and many others) agree that this is error prone. That kind of
mistake is reasonably common among bugs that people ask for help with
here. See below for "better" ways to handle this. The reason that you
need the separate declarations is because of independent compilation.
Fortran was originally designed so that the main program and the
external function could be compiled completely independently. They could
be in separate files compiled at different times, neither file having
access to any information from the other. Both the function and the
program calling it need to know the type in order to compile the
appropriate code.
> If I've understood well, is it possible to encapsulate a function or a
> procedure inside of a module.
> In this case there isn't the need to declare the kind of output of the
> function twice, but an additional USE statement should be used.
> According to Chapman, it seems that it's better to encapsulate every
> function inside a module, to increare the probability to catch coding
> errors with the compiler.
> Is it always true? It seems a redundant form of coding.
I tend to disagree with most of what Chapman says... but in this case we
agree. It sounds to me lie you are misinterpreting something here, but I
can't quite tell what. Putting the function is a module is how you
*AVOID* the redundancy of declaring the type multiple times. I'm not
sure how you think this is redundant. Either you are missing something
(and I'm not sure what) or perhaps you are just using the word
"redundant" with a meaning close to the opposite of its usual one.
Hmm. Perhaps you are thinking that each function needs its own module.
While it is possible to code that way, and some people even use a style
like that, I don't personally like that style. If that is what Chapman
is advocating, then I disagree with him after all. (After perusing his
book in a library, I decided not to buy it, so I don't have a copy to
check).
The usual recommendation is more to group related procedures into a
module. Exactly how to best group them is a bit more of an art -
somewhat related to the art of deciding what functionality to
encapsulate into a procedure in the first place. For small programs, one
can sometimes get by with just putting all of the procedures in a single
module; I've been known to do that.
Declaring the type is actually only a tiny part of why putting your
procedures in modules is a good idea. It isn't just the type, but pretty
much everything that the caller needs to know in order to invoke the
procedure. With f90, that turns out to be an awful lot of things. If
your procedure (or the invocation of it) uses any of that longish list
of things, then the caller has to have an explicit interface for the
procedure. By far the easiest way to get such an explicit interface is
to put the procedure in a module (or an internal procedure will do in
some cases). In that case, the interface information "comes"
automatically with the USE statement. The worst way is to write an
interface body for the procedure. If you think (as I do) that
duplicating the procedure type declaration is poor and error prone, wait
until you see the practice of duplicating the entire procedure
interface; that's what you get stuck with if you don't use modules.
If you make it a habit to put all of your procedures in modules, then
you won't have to keep track of the list of cases where you need an
explicit interface; you will always have one anyway.
> Some manuals says that LOGICAL variables occupies 4 bytes.
> Why? I would suppose that 1 bit was enough to contain a single bit
> information, like true/false (1/0).
Two things, well, make it three. Ok, four.
1. First and most important is that this is *NOT* something you should
count on in general. The space taken by a logical is not specified by
the standard. By far the most common size is 4 bytes, but that depends
on the particular compiler. Fortran is not even restricted to machines
that have things sized in bytes.
2. Although you might think in theory that a logical could take only a
single bit, most (darn near all) computers don't do very well at
bit-level addressing. The hardware doesn't tend to support it. In order
to get at a bit from memory, you tend to have to get at least a byte
(and depending on the hardware, sometimes more) of data and then pull
the desired bit out. Storing a bit is even messier, assuming that you
don't want to mess with adjacent bits.
3. Partly because of hardware considerations such as item 2 above,
Fortran traditionally specified that integers, single precision reals,
and logicals (once they were added to the language) all had the same
size. It did not specify what the size was, but it specified that they
be the same. That simplified life on machines where all data was
naturally accessed in sizes of a "word", which was typically the natural
size for darn near everything on those machines. That bit of history is
why default logical is 32 bits (at least on compilers where that's the
size of default real) instead of, say, 8 bits, which most of today's
machines can address reasonably.
4. The 4 byte thing is only for default logical. Although that was the
only standard possibility prior to f90, f90 allows the specification of
a logical kind. It is up to the compiler whether to support extra
logical kinds. Support for 1-byte kinds is reasonably common. In theory,
a compiler could support a 1-bit kind, but I've never seen it done,
probably for reasons related to item 2 above.
Unless you have huge arrays of logicals or some such thing, you
shouldn't be fussing with their sizes anyway.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
< I've started to study Fortran 90+ about one week ago and I've found
< some things I can't understand well.
< Since now I was used to write programs using Matlab scripting languange,
< so I almost know the meaning of the most important elements of a
< programming language.
There are some important differences between interpreted languages
like Matlab (and S, Mathematica, etc.) and compiled languages like
Fortran and C.
< Below I've written my doubts. I only want to understand how Fortran
< works, then excuse me for possible errors and/or "stange" questions.
< (1)
< If I have understood well, there is the need to specify the type of the
< output of a function both in the function itself and in the "main"
< program.
In an interpreted language, type can (and often is) dynamically
determined. A variable takes on the type of the value assigned
to it. For a compiled language the type has to be known such
that the appropriate instructions can be generated.
(snip)
< Why have I to specify twice the type of the output of a function?
< Is it possible to avoid this double declaration? I'm afraid to double
< the probability of a mistake.
See below, but the underlying reason is separate compilation.
If the two are compiled separately, each has to know the type
of instructions to generate. There are ways to make it easier,
such as modules, but the important idea is that the type must
be known at compile time for each one.
< If I've understood well, is it possible to encapsulate a function or a
< procedure inside of a module.
< In this case there isn't the need to declare the kind of output of the
< function twice, but an additional USE statement should be used.
< According to Chapman, it seems that it's better to encapsulate every
< function inside a module, to increare the probability to catch coding
< errors with the compiler.
With modules, when you compile the module the appropriate file
will be generated for the USE statement to read and learn the
appropriate types.
< Some manuals says that LOGICAL variables occupies 4 bytes.
< Why? I would suppose that 1 bit was enough to contain a single bit
< information, like true/false (1/0).
For Fortran, it is so that INTEGER, REAL, and LOGICAL are all
the same size. (That has been true for Fortran, independent
of the actual size.)
A more important reason is that it is more efficient for
many machines. Bit addressing is rare. LOGICAL was added
to Fortran before byte addressable machines became popular.
When they did, IBM added LOGICAL*1, but even then
for scalar variables LOGICAL*4 was (the default and) often
more efficient.
-- glen
Richard Maine
> Lurkos <lurkos...@gmail.com> wrote:
> < Why have I to specify twice the type of the output of a function?
> < Is it possible to avoid this double declaration? I'm afraid to double
> < the probability of a mistake.
>
> See below, but the underlying reason is separate compilation.
I would say that it is independent compilation, rather than just
separate compilation. The two concepts are related, but not identical.
The distinction does turn out to be important. Fortran supports separate
compilation of a module and the program units that use the module, but
that separate compilation is not independent.
See C.8.2 for f2003 for a discussion of this.
glen herrmannsfeldt
(snip)
< I tend to disagree with most of what Chapman says... but in this case we
< agree. It sounds to me lie you are misinterpreting something here, but I
< can't quite tell what. Putting the function is a module is how you
< *AVOID* the redundancy of declaring the type multiple times. I'm not
< sure how you think this is redundant. Either you are missing something
< (and I'm not sure what) or perhaps you are just using the word
< "redundant" with a meaning close to the opposite of its usual one.
I believe the comment is on the need for the USE.
While significantly less work than declaring the type, it
must be done such that modules work correctly (at all).
Anyone used to dynamic typing of an interpreted language will
be surprised by the typing requirements of any compiled language.
-- glen
robin
news:20090510191854...@L622132.user.x-privat.org...
With the help of the CONTAINS statement, you could
place the function inside the main program thus:
PROGRAM main
IMPLICIT NONE
REAL :: functiontest !<--- 1st declaration
REAL :: number
REAL :: value = 100
number = functiontest(value)
CONTAINS
FUNCTION functiontest(argument)
IMPLICIT NONE
REAL :: functiontest !<--- 2nd declaration
REAL, INTENT(IN) :: argument
functiontest = argument * 2
END FUNCTION functiontest
END PROGRAM main
viper-2
>
> I tend to disagree with most of what Chapman says...
> is advocating, then I disagree with him after all. (After perusing his
> book in a library, I decided not to buy it, so I don't have a copy to
> check).
>
Having discovered that Fortran won't be replaced by Fortress anytime
soon, It's about time I upgraded the Fortran segment of my programming
bookshelf beyond Radford.:-)
My Googling pointed me towards Chapman, so what Fortran text books do
you recommend then? I do plan to get a copy of "The Fortran 2003
Handbook" by Maine, Hendrickson et al. but a couple of other texts
would be fine.
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: a...@codeartnow.com
Ian Bush
> On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
>
> > I tend to disagree with most of what Chapman says...
>
> <snip> If that is what Chapman
>
> > is advocating, then I disagree with him after all. (After perusing his
> > book in a library, I decided not to buy it, so I don't have a copy to
> > check).
>
> Having discovered that Fortran won't be replaced by Fortress anytime
> soon, It's about time I upgraded the Fortran segment of my programming
> bookshelf beyond Radford.:-)
>
> My Googling pointed me towards Chapman, so what Fortran text books do
> you recommend then? I do plan to get a copy of "The Fortran 2003
> Handbook" by Maine, Hendrickson et al. but a couple of other texts
> would be fine.
>
"Fortran 95/2003 Explained" Michael Metcalf, John Reid, Malcolm Cohen,
published by OUP
Ian
Jason Blevins
> On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
>>
>> I tend to disagree with most of what Chapman says...
> <snip> If that is what Chapman
>> is advocating, then I disagree with him after all. (After perusing his
>> book in a library, I decided not to buy it, so I don't have a copy to
>> check).
>>
>
> Having discovered that Fortran won't be replaced by Fortress anytime
> soon, It's about time I upgraded the Fortran segment of my programming
> bookshelf beyond Radford.:-)
>
> My Googling pointed me towards Chapman, so what Fortran text books do
> you recommend then? I do plan to get a copy of "The Fortran 2003
> Handbook" by Maine, Hendrickson et al. but a couple of other texts
> would be fine.
Personally, I'm hoping to find a copy of "Algorithms and Data Structures
in F and Fortran" by R. A. Vowels. Unfortunately it's out of print and
I can't even find a used copy, but I'm keeping my eyes open...
Depending on your interests, you might find it interesting too (the
source code is still available though):
http://www.users.bigpond.com/robin_v/f-cont.htm
Robin, any idea where one might find a copy of the book? Perhaps
there's a second edition in the works? :)
viper-2
If the book is going to stay out of print, might the author consider
making it available on your new Fortran Wiki?
I quite like the emphasis on algorithms.
viper-2
>
>
> With the help of the CONTAINS statement, you could
> place the function inside the main program thus:
>
> PROGRAM main
> IMPLICIT NONE
> REAL :: functiontest !<--- 1st declaration
> REAL :: number
> REAL :: value = 100
>
> number = functiontest(value)
>
> CONTAINS
>
> FUNCTION functiontest(argument)
> IMPLICIT NONE
> REAL :: functiontest !<--- 2nd declaration
> REAL, INTENT(IN) :: argument
>
> functiontest = argument * 2
>
> END FUNCTION functiontest
>
> END PROGRAM main
To further reduce the "redundant" typing, you could also include the
type in the function statement itself:
CONTAINS
REAL FUNCTION functiontest(argument)
IMPLICIT NONE
REAL, INTENT(IN) :: argument
functiontest = argument * 2
END FUNCTION functiontest
As an internal procedure, you wouldn't be able to pass the function as
an argument to another procedure, though.For that, I believe you would
need to treat it as an external function, preferably in a module.
michael...@compuserve.com
>For that, I believe you would
>need to treat it as an external function, preferably in a module.
Hate to be pedantic, but there are external procedures and there are
module procedures, and never the twain shall meet.
Regards,
Mike Metcalf
James Van Buskirk
news:7ee76a29-554e-409d...@r34g2000vbi.googlegroups.com...
> Hate to be pedantic, but there are external procedures and there are
> module procedures, and never the twain shall meet.
Isn't it possible that an external procedure, if there is an
interface block for it in a module, may be named in a MODULE
PROCEDURE statement? Or that a module procedure with the BIND(C)
attribute and a suitable binding name may be referenced as an
external procedure? Or a dummy argument can be an external
procedure even though the actual argument is a module procedure?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Richard Maine
> On 11 May, 15:07, viper-2 <visio...@mail.infochan.com> wrote:
> > On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
> >
> > > I tend to disagree with most of what Chapman says...
> > My Googling pointed me towards Chapman, so what Fortran text books do
> > you recommend then? I do plan to get a copy of "The Fortran 2003
> > Handbook" by Maine, Hendrickson et al. but a couple of other texts
> > would be fine.
> >
> "Fortran 95/2003 Explained" Michael Metcalf, John Reid, Malcolm Cohen,
> published by OUP
I've got a bit of a conflict of interest in recommending Fortran texts.
(It isn't quite what one might think of as the most "obvious" conflict;
the amount of money I get from a single book sale wouldn't buy a soft
drink, much less the "traditional" nominal beer bet. The conflict has
more to do with our contract with the publisher, which says that I'm not
supposed to do things that would have a negative effect on the sales).
But tiptoeing around that, I'll agree with the above recommendation of
MR&C. It is widely recommended here. It is a lot shorter than our book.
Partly that's because our book tries to be a comprehensive handbook for
the whole language, including the obscure corners. I know all three of
them, John and Malcolm petty well, and they are nice guys as well.
I've never seen Robin's book, mentioned elsethread, and don't intend to.
Sorry. But I find it hard to reconcile the apparent level of Fortran...
um... let's call it "expertise" exhibited here with authoring a viable
book. I find it even harder to reconcile good advice with the apparent
level of insight shown here into what problems people might be running
into. At times, I can't tell whether the errors and misinterpretations
are an intentional "game" or reflect his actual understanding. Both seem
far out enough for it to be hard for me to imagine. At times, I've been
impressed in a way with the degree of Fortran knowledge that I'd think
it must take to come up with an example that could simultaneously appear
to illustrate a point, yet be so completely wrong (fun with TRIM comes
particularly to mind). It's been a long time since I even read his
posts, so perhaps there has been reform. Maybe it's a great book, but
I'll never know first hand.
I've recently mentioned Cooper Redwine's "Upgrading to Fortran 90" for
users already experienced in f77, though it is long out of print and the
used prices at Amazon US seem exhorbitant.
Richard Maine
> <michael...@compuserve.com> wrote in message
> news:7ee76a29-554e-409d...@r34g2000vbi.googlegroups.com...
> > Hate to be pedantic, but there are external procedures and there are
> > module procedures, and never the twain shall meet.
>
> Isn't it possible that an external procedure, if there is an
> interface block for it in a module, may be named in a MODULE
> PROCEDURE statement?
No. It can be in a PROCEDURE statement, but you can't then use the
optional MODULE keyword; or if you are prior to f2003 when the MODULE
part was made optional, then just no.
I don't know why that particular silliness was initially there. Probably
just an oversight; I can't think of any other reason. But that's the way
it was.
> Or that a module procedure with the BIND(C)
> attribute and a suitable binding name may be referenced as an
> external procedure?
That one probably yes. It's a funny case.
> Or a dummy argument can be an external
> procedure even though the actual argument is a module procedure?
No. A dummy procedure is never an external procedure - or a module
procedure either. It is a dummy procedure, which is a separate kind of
thing entirely. Yes, I know you can use the EXTERNAL attribute to
declare a dummy procedure, but on one of those horrible historical
naming oddities, the EXTERNAL attribute does not mean that a procedure
is external. The description of the external attribute says something
very close to that (and I'm to lazy to go grab the standard from my desk
10 feet from here, but this is close) the EXTERNAL attribute specifies
that an entity is either an external procedure, a dummy procedure, or a
block data.
Richard Maine
> To further reduce the "redundant" typing, you could also include the
> type in the function statement itself:
I won't argue the point, as it is a style question on which opinions
legitimately vary. I will just briefly note that I don't like that
particular style. Some of my reasons are more stylistic and thus
particularly not worth arguing, but I'll note that there are some cases
where there are more concrete "issues".
I don't even recall exactly which variants are technically standard and
which ones aren't. The fact that I can't recall this illustrates part of
the problem. It gets quite subtle. There have been formal interpretation
requests (ones that were not at all trivial and might even have resulted
in corrections to the standard) in this area. There are special cases in
the standard for some stuff, but not for others. I prefer to just avoid
the whole mess.
The basic problem is that the function statement is awfully early in the
source code of the function. In fact, it is without exception the first
statement in the function. If you are using only intrinsic types and
don't specify kinds or lengths, then things are simple. But anything
else gets messy because it might reference things that haven't yet been
declared.
Consider such things as
type(my_type) function f(...)
type my_type
...
End type
or
real(kind=wk) f(...)
use kinds_module, only: wk
As I said, I don't recall which of these are valid. I prefer to just
avoid the complication.
James Van Buskirk
news:1izjr3u.1vz1f9ueifqpsN%nos...@see.signature...
> James Van Buskirk <not_...@comcast.net> wrote:
>> Isn't it possible that an external procedure, if there is an
>> interface block for it in a module, may be named in a MODULE
>> PROCEDURE statement?
> No. It can be in a PROCEDURE statement, but you can't then use the
> optional MODULE keyword; or if you are prior to f2003 when the MODULE
> part was made optional, then just no.
> I don't know why that particular silliness was initially there. Probably
> just an oversight; I can't think of any other reason. But that's the way
> it was.
C:\gfortran\clf\extern_module>type extern_module.f90
module mod1
implicit none
interface
subroutine specific(x)
real x(:)
end subroutine specific
end interface
end module mod1
module mod2
use mod1
implicit none
interface generic
module procedure specific
! procedure specific
end interface generic
end module mod2
program extern_module
use mod2
implicit none
real x(3)
call generic(x)
end program extern_module
subroutine specific(x)
implicit none
real x(:)
write(*,'(a,i0)') 'size(x) = ', size(x)
end subroutine specific
C:\gfortran\clf\extern_module>gfortran extern_module.f90 -oextern_module
extern_module.f90:14.31:
module procedure specific
1
Error: 'specific' at (1) is not a module procedure
extern_module.f90:20.11:
use mod2
1
Fatal Error: Can't open module file 'mod2.mod' for reading at (1): No such
file
or directory
gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
But uncommenting the procedure line and commenting the module
procedure line I get:
C:\gfortran\clf\extern_module>gfortran extern_module.f90 -oextern_module
C:\gfortran\clf\extern_module>extern_module
size(x) = 3
So you're right. Kind of wierd that the compiler is forced to keep
a flag or something in the data structure that describes the interface
to a procedure it accesses via use association just so that it can
distinguish between a module procedure and one that is not. I
wouldn't have expected that, but then there are other limitations I
wouldn't have expected regarding the module procedure statement as
well.
viper-2
>
Thanks; I do recall glimpsing a thread where Maine recommended
Metcalf. I found his tutorial here:
<http://wwwasdoc.web.cern.ch/wwwasdoc/WWW/f90/f90.html>
viper-2
I'm still new to the terminology. This is why I need to get your
book!:-)
viper-2
> viper-2 <visio...@mail.infochan.com> wrote:
> > To further reduce the "redundant" typing, you could also include the
> > type in the function statement itself:
>
> I won't argue the point, as it is a style question on which opinions
> legitimately vary. I will just briefly note that I don't like that
> particular style. Some of my reasons are more stylistic and thus
> particularly not worth arguing, but I'll note that there are some cases
> where there are more concrete "issues".
I seem to have a preference for terse code as long as it doesn't
create "issues" - which I'm yet to learn about.
viper-2
> Ian Bush <ianbush.throwaway.acco...@googlemail.com> wrote:
> > On 11 May, 15:07, viper-2 <visio...@mail.infochan.com> wrote:
> > > On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
>
> > > > I tend to disagree with most of what Chapman says...
> > > My Googling pointed me towards Chapman, so what Fortran text books do
> > > you recommend then? I do plan to get a copy of "The Fortran 2003
> > > Handbook" by Maine, Hendrickson et al. but a couple of other texts
> > > would be fine.
>
> > "Fortran 95/2003 Explained" Michael Metcalf, John Reid, Malcolm Cohen,
> > published by OUP
>
> But tiptoeing around that, I'll agree with the above recommendation of
> MR&C. It is widely recommended here. It is a lot shorter than our book.
> Partly that's because our book tries to be a comprehensive handbook for
> the whole language, including the obscure corners.
Then one could work through Metcalf & Co, and use Maine & Co. as
Reference.
> I've recently mentioned Cooper Redwine's "Upgrading to Fortran 90" for
> users already experienced in f77, though it is long out of print and the
> used prices at Amazon US seem exhorbitant.
>
Thanks.
Jason Blevins
> On May 11, 10:15 am, Ian Bush
> <ianbush.throwaway.acco...@googlemail.com> wrote:
>> On 11 May, 15:07, viper-2 <visio...@mail.infochan.com> wrote:
>> > On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
>>
>> > > I tend to disagree with most of what Chapman says...
>>
>> > <snip> If that is what Chapman
>> > > is advocating, then I disagree with him after all. (After perusing his
>> > > book in a library, I decided not to buy it, so I don't have a copy to
>> > > check).
>>
>> > Having discovered that Fortran won't be replaced by Fortress anytime
>> > soon, It's about time I upgraded the Fortran segment of my programming
>> > bookshelf beyond Radford.:-)
>>
>> > My Googling pointed me towards Chapman, so what Fortran text books do
>> > you recommend then? I do plan to get a copy of "The Fortran 2003
>> > Handbook" by Maine, Hendrickson et al. but a couple of other texts
>> > would be fine.
>>
>> "Fortran 95/2003 Explained" Michael Metcalf, John Reid, Malcolm Cohen,
>> published by OUP
>>
>> http://www.amazon.com/Explained-Numerical-Mathematics-Scientific-Comp...
>
> Thanks; I do recall glimpsing a thread where Maine recommended
> Metcalf.
The Fortran 2003 Handbook is very high on my book wishlist as well.
If you could only buy one additional book, I would also recommend MR&C.
It's on my quick access shelf, within arms reach from where I'm sitting
right now. It's the book from which I learned Fortran 90+ (previously I
only knew F77 as learned from various courses and tutorials). I found
that it got me up to speed very fast in the beginning, but it's also a
great reference for more advanced F2003 concepts.
viper-2
OK. Operating word is "speed".
Phillip Helbig---remove CLOTHES to reply
nos...@see.signature (Richard Maine) writes:
> Two things, well, make it three. Ok, four.
I didn't expect the Spanish Inquisition!
Erik Toussaint
Nobody expects the Spanish Inquisition!
(Sorry, couldn't resist it.)
R Vowels
> Personally, I'm hoping to find a copy of "Algorithms and Data Structures
> in F and Fortran" by R. A. Vowels. Unfortunately it's out of print and
> I can't even find a used copy, but I'm keeping my eyes open...
> Depending on your interests, you might find it interesting too (the
> source code is still available though):
>
> http://www.users.bigpond.com/robin_v/f-cont.htm
>
> Robin, any idea where one might find a copy of the book? Perhaps
> there's a second edition in the works? :)
Suggest keeping tabs on Amazon.
I'm working on a PDF version. May be some time ...
R Vowels
news:ce2136e5-6a0d-4418...@s16g2000vbp.googlegroups.com...
I'm working on a PDF version.
viper-2
> "viper-2" <visio...@mail.infochan.com> wrote in message
If you've got a mailing list to announce the pdf version please add
<a...@codeartnow.com>. Thanks.
Paul van Delst
> On May 10, 4:02 pm, nos...@see.signature (Richard Maine) wrote:
>> I tend to disagree with most of what Chapman says...
> <snip> If that is what Chapman
>> is advocating, then I disagree with him after all. (After perusing his
>> book in a library, I decided not to buy it, so I don't have a copy to
>> check).
>>
>
> Having discovered that Fortran won't be replaced by Fortress anytime
> soon, It's about time I upgraded the Fortran segment of my programming
> bookshelf beyond Radford.:-)
>
> My Googling pointed me towards Chapman, so what Fortran text books do
> you recommend then? I do plan to get a copy of "The Fortran 2003
> Handbook" by Maine, Hendrickson et al. but a couple of other texts
> would be fine.
Is it just my domestic blindness, or does the f95/2003 Chapman book contain nothing about
C-interop? I can't find a mention of it at all (well I did find a single ref to the
ISO_C_BINDING intrinsic module, but that was it).
cheers,
paulv