Hello all! 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).
> (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/
Lurkos <lurkos.use...@gmail.com> wrote: > 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
< 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 herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Lurkos <lurkos.use...@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.
-- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
(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.
> Hello all! > 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.
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
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.
> 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
> 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):
> > 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):
> 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.
> 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
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
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 | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
> 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 | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
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 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.
-- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
> James Van Buskirk <not_va...@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
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:
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.
-- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
<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
On May 11, 1:35 pm, nos...@see.signature (Richard Maine) wrote:
> 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.
> 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
> I've got a bit of a conflict of interest in recommending Fortran texts. <snip> > 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.
> 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
> 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.
-- Jason Blevins Ph.D. Candidate, Department of Economics, Duke University http://jblevins.org/
On May 11, 4:07 pm, Jason Blevins <jrble...@sdf.lonestar.org> wrote:
> On May 11, 2009, at 3:02 PM, viper wrote:
> > 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.
