Fortran Basics
baalzamon.moridin
I am converting some fortran 77 code into matlab. There are various
questions that have cropped up. As I prgress through my conversion
process i will add them to this topic. For now my first question is;
What is 0.0D0?
the context it is being used in is;
IF (A.NE.0.0D0) GOTO 20
As an initial guess I was thingking it is a 'precise' definition of
zero....? Thus if A is not 'exactly' to zero then jump to statement
20...
steve
wrote:
Have you tried "Fortran tutorial" with your favor search engine?
Google seems to think that there are about 547000 possible sites
that might help.
Additionally, wikipedia's article is well written. It might
help with this and other questions.
To answer your question, 0.0d0 is a double precision literal
constant.
--
steve
Reinhold Bader
baalzamon.moridin schrieb:
> Howdy there,
> I am converting some fortran 77 code into matlab. There are various
> questions that have cropped up. As I prgress through my conversion
> process i will add them to this topic. For now my first question is;
> What is 0.0D0?
0.0D0 is a constant of type "double precision real", whereas 0.0 is a constant
of type "default real". Typically, today's implementations use a IEEE conforming
representation using 4 bytes for default reals, and 8 bytes for double precision
reals. Since zero is exactly representable, there will not be any difference
between 0.0 and 0.0D0 as far as evaluating the logical expression below is
concerned.
> the context it is being used in is;
> IF (A.NE.0.0D0) GOTO 20
> As an initial guess I was thingking it is a 'precise' definition of
> zero....? Thus if A is not 'exactly' to zero then jump to statement
> 20...
Regards
Reinhold
Richard Maine
> I am converting some fortran 77 code into matlab. There are various
> questions that have cropped up. As I prgress through my conversion
> process i will add them to this topic. For now my first question is;
> What is 0.0D0?
Double precision zero.
> the context it is being used in is;
> IF (A.NE.0.0D0) GOTO 20
> As an initial guess I was thingking it is a 'precise' definition of
> zero....? Thus if A is not 'exactly' to zero then jump to statement
> 20...
Well, sort of, but not really. The D0 means double precision. It does
not mean exact. On the other hand, the .NE. does mean exact - always.
That really has nothing to do with the D0. There is no such thing as a
"sort of equal" test in the language. You can code one yourself, and it
is even reasonably common to do so, but there is nothing like that built
into the language. On the third hand, zero is always going to be exact
in any precision anyway.
So the test does mean to jump if A is not exactly equal to zero, but
that has nothing to do with anything particularly closely related to the
D0.
The D0 is presumably (you don't show the declarations, so it is just a
guess, but probably a pretty good one) because the "A" is double
precision and it is considered best style to compare things of the same
precision. It is allowed to compare things of different precision, but
that is often discouraged because it can give surprising results. The
surprises won't happen for 0.0, but there is much to be said for
applying such rules of stylel consistently instead of trying to figure
out when you can get by without them.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
baalzamon.moridin
fortran compiler.
Furthermore I really do not want to end up having to learn fortran
beyond what i need for translation.
Though I will act upon your advice and look up some more tutorials.
Tobias Burnus
> [...]however, I do not have a fortran compiler.
That can easily be solved: Simply install a free one, e.g.,
gfortran (http://gcc.gnu.org/wiki/GFortranBinaries)
or
g95 (http://www.g95.org/)
Tobias
steve
wrote:
If you do not have a Fortran compiler, how are you going to
test that your Matlab translation gives the same result as
the original Fortran code?
gfortran and g95 are free compilers.
http://gcc.gnu.org/wiki/GFortran
http://www.g95.org/
There are a few commercially available compilers that provide a
'free' version under certain conditions (e.g., academic research
or noncommercial use). Silverfrost is one such compiler.
If the code is Fortran 77, you might take a peek at a book
written by Clive Page. It can be found at
http://www.star.le.ac.uk/~cgp/fortran.html
search for "Professional Programmer's Guide to Fortran77"
on the page. It a fairly concise book and with your
background in Matlab, I suspect you could read it in
a few hours.
--
steve
dpb
> Howdy there,
> I am converting some fortran 77 code into matlab. There are various
> questions that have cropped up. As I prgress through my conversion
> process i will add them to this topic. For now my first question is;
> What is 0.0D0?
That is a DOUBLE PRECISION constant (as opposed to single, default
floating point constant). W/O the "D", it is single precision.
For a zero value, promotion to a double will still leave precisely zero;
the difference occurs when the value is not exactly representable.
Fortran will convert the single precision value to double on an
assignment, but it is a single precision value in a double precision
variable on doing so for a loose way of saying it.
IOW, in general, the "D" is important for doubles.
Here's a case where in Matlab it won't matter so much; Matlab uses
double as it's default data type and so the effect of the "D" is gained
implicitly w/o being specifically required.
Given the questions you've asked in cs-sm and now this, you clearly need
to start by finding a Fortran reference from the uni library or at a
minimum link to the online manual of a compiler to be able to look up
such stuff.
--
baalzamon.moridin
Thus I can test if my code yields the same results.
I intend to write two versions,
(i) Full conversion,
(ii) Call the fortran code directly.
Both will be tested for results.
On a side note, one of my codes uses Assign a lot. Any ideas on
what this does?
Richard Maine
> On a side note, one of my codes uses Assign a lot. Any ideas on
> what this does?
Oh, yukk! Assign is a bit of an abomination from the past, which is no
longer in the language. Although simple enough in some ways, assign has
an arcane collection of warts with surprising consequences. If used
sparingly and in simple ways, it might not be too bad and can readily be
translated into other constructs. But if a program uses it "a lot", I'd
take that as a bad sign. Most programs I have seen that used it "a lot"
were the kind of incomprehensible mess that was best handled by throwing
them out and restarting from scratch.
The short version is that assign assigns an integer variable with a
value that is a statement label. You can then subsequently use that
integer variable in a few limitted contexts as a stand-in for that
statement label.
Gordon Sande
<baalzamo...@gmail.com> said:
ASSIGN is a very old Fortran feature that is often a red flag for
spaggetti code.
Often very old code.
if you have
GOTO i ( 100, 200 )
and
ASSIGN 100 TO i
then the GOTO i ... becomes GOTO 100 in practice. If there had been an
ASSIGN to 200 then the GOTO would have the other effect. It is an old way
of branching around inside a program with the value of i set differently.
And no, i=100 means something very different so do not try this instead.
Sometimes the branching will be well disciplined as it is allowing a single
piece of code to used repeatedly with the ASSIGN telling where to branch back
to. And sometimes you are not so lucky!
Now we would design the code differently. At worse there would be a SELECT
with a bunch of GOTOs.
glen herrmannsfeldt
> baalzamon.moridin <baalzamo...@gmail.com> wrote:
>> On a side note, one of my codes uses Assign a lot. Any ideas on
>> what this does?
> Oh, yukk! Assign is a bit of an abomination from the past, which is no
> longer in the language. Although simple enough in some ways, assign has
> an arcane collection of warts with surprising consequences.
It seems that ASSIGN and assigned GOTO were added before SUBROUTINE
and CALL, as a method to allow for internal subroutines. You ASSIGN
the statement you want to return to, and then GOTO the subroutine.
This is also the reason for "extended range of DO."
Now, with subroutine calls we never consider that as going out
of, and returning into the range of a DO, though that is exactly
what happens.
> If used sparingly and in simple ways, it might not be too bad
> and can readily be translated into other constructs.
> But if a program uses it "a lot", I'd take that as a bad sign.
> Most programs I have seen that used it "a lot" were the kind
> of incomprehensible mess that was best handled by throwing
> them out and restarting from scratch.
Last I saw them used, they were generated by a macro processor
as an expansion for a fake internal subroutine. It is best not
to look at the code generated by many programs generating source
code in any language.
> The short version is that assign assigns an integer variable with a
> value that is a statement label. You can then subsequently use that
> integer variable in a few limitted contexts as a stand-in for that
> statement label.
More specifically, a popular implementation stores the address
of the statement in the variable, and the GOTO jumps to that address.
Likely faster than computed GOTO using index values, which is
one possible replacement for it.
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> More specifically, a popular implementation stores the address
> of the statement in the variable,
And some of the messier arcane bits come up when a default integer (the
only standard kind in that era) was not large enough to hold such an
address. You then often get things like a second "shadow variable" (I'm
not sure whether that's quite the right terminology, but something like
that), which holds the address, but is not actually in the same memory
location as the "regular" integer variable. That in turn has all kinds
of subtle consequences that can bite you if you don't follow the
surprisingly strict letter of the standard. For example,
assign 10 to i
j = i !--- save the value.
.... do some other things, possibly using i, but leaving j alone
i = j !-- restore the value
is not guaranteed to work as you'd think. The j=i is only allowed if i
is defined with a nnumeric value; a statement label value doesn't count
(even though they look like numbers in the source code).
baalzamon.moridin
bar back down to 10%!
I think there are around 8 assign labels, along with the usual side
dishes of GO TO.
On a secondary note, I was informed that if I convert the F77 code
(and from what people
are telling me - also pre F77) to F90 this will make it easier to read
(understand)?
Richard Maine
> On a secondary note, I was informed that if I convert the F77 code (and
> from what people are telling me - also pre F77) to F90 this will make it
> easier to read (understand)?
Well.... sort of. But then that's probably not a particularly useful
comment for your situation because in order to do a good job of
converting it into f90, you would first have to understand it.
There are some automatic converters for some things, but those are not
likely to be silver bullets. Automatic language converters are rather
known for producing output that is hard to read.
After all, it isn't that being in f90 will inherently make something
easy to read. You can write incomprehensible messes in any language.
Examples exist. (Plenty of them.) It is more that f90 has facilities
that help the programmer write code that is easy to read, if the
programmer appropriately takes advantage of them
dpb
Richard addressed the "simply convert this to F90+" question -- I don't
think it helps that much either, simply to recast whatcha' got and
rewriting the ASSIGNs will be a problem that won't go away w/o, as he
says, understanding full well what they're doing.
As for the first question of the progress bar, I think you ought to
seriously consider the route of testing this code that it does what you
think it does (and that's what you need/want) and then if the need is to
have the calculation in Matlab, mex it. _THEN_, you've got something
going and could decide whether it was actually worth converting to
actual Matlab code at a later date.
$0.02, etc., etc., etc., of course...
--
baalzamon.moridin
Do you mean testing my converted code or the original? I know the
original works fully.
As for my attempt at a conversion, well once I have completed the
translation I will test it against
original. As for this 'mex' approach...I am seriously considering it.
But only after I've done the conversion.
<I have become rather obsessed with it now> Saying that I think that
more than likely I'll end up caling the fortran functions in to
MATLAB
and working on them from there....
baalzamon.moridin
> ...I think you ought to
> seriously consider the route of testing this code that it does what you
> think it does (and that's what you need/want)
dpb
> @ dpb
...
> ... As for this 'mex' approach...I am seriously considering it.
> But only after I've done the conversion.
I'm suggesting the other way 'round, particularly if, indeed, the code
satisfies in all material respects as it currently is. I don't have a
clue how large it is but given the number of uglies you've mentioned, it
seems likely the conversion could take a while.
So, if you know it works, why not simply add the interface to call it
and be done?
> <I have become rather obsessed with it now> Saying that I think that
> more than likely I'll end up caling the fortran functions in to
> MATLAB and working on them from there....
The first part I presume would be making it a mex-function; I don't know
what the last phrase means unless you mean to use the results from the
Fortran mex-file inside Matlab--if so, that's what I was suggesting.
On the question of testing, I hadn't seen the you had an existing
executable and therefore wasn't sure other than by reading source you
knew the routine(s) actually performed as you expected.
Given that, see above... :)
--
baalzamon.moridin
format etc.
Today I shall look into mex stuff. If anything I shall recreate the
main program and some of the intial subroutines
in matlab and then call some of the horrid code in - like the one with
the assigns, as well as the routines such as
DAXPY etc. Ultimately, at the moment I use the fortran exe, which
generates text files, that I load into matlab for analysis.
Some of the results are mathematical realisations that are of no use
to me, as such I feel that by having the bulk of the
code in matlab, then calling these routines in the manner you have
mentioned, I could create arrays of data, that is
filtered according to a stle of my choosing.
mecej4
I hope that you are aware that you can also call Matlab from the Fortran
code.
One major factor in deciding whether to make a .mex out of the Fortran or to
call Matlab from Fortran is the division of labor. If the Fortran routine
does much less work than Matlab, it may be advantageous to have it call
Matlab.
The second issue is error handling. This is a non-trivial issue since there
are two error contexts to worry about, and means for reporting Fortran
errors in Matlab (or vice versa) need to be provided. If the .mex code is
short, you can do your best to make it error free, and keep your fingers
crossed. Otherwise, you have to do a good chunk of code writing to manage
and report errors.
-- mecej4
dpb
Another alternative if the point is simply to analyze results from the
code in Matlab rather than a "must have" of the whole system as a Matlab
application would be to just look at the section of the code that is
creating the output and modify it to suit -- you could, for example,
neuter the output you don't want/use (or, of course, if it's factored
well enough, not call that portion of the model).
Also, you could easily enough change the output from text files to write
binary files that could be loaded in Matlab w/ load() more quickly.
You could make these files have any structure desired relatively easily
I'd think. You would, need to use a compiler that supports "stream"
output which wasn't a Standard component of Fortran until F2003, but
virtually all compilers had extensions to do so; only a very few didn't.
That way you could actually avoid the mex-ing thing altogether.
Depending on your needs, you might also be able to use the ability of
Matlab to spawn a process to make the interaction w/ the code from
Matlab by using it to create input and execute that via the dos()
command and friends then load the binary file when done. Saving, I'd
think, quite a lot of effort in converting already-working code.
Again, $0.02, etc., etc., etc., ...
--
baalzamon.moridin
re: calling from binary file
An interesting alternative, that I did once consider, however, with
the large number of times I need to call this code text file
generation is something i would like to avoid. As for surpressing the
output, well that does sound good. I will go over the code later and
see if the io code splits the task with the output code. As long as I
could control the input and have the output going straight to an array
in matlab that would be adequate. Though it would steal my spare time
reallocation which I gave into the conversion....
By the By do I need an actual editor for writing fortran....or can I
use notepad and save it with the correct extension? Notepad opens the
file and shows no encrypted segments?
Gordon Sande
<baalzamo...@gmail.com> said:
If you save as any type of formatted (in the word processing sense) file
it is unlikely that a compiler will be able to deal with the formatting
information.
You must save as text.
Do not rely on any automatic line wrapping as the text will be a very long
line which may well exceed the compiler limit, to say nothing of the confusion
of having all those Fortan statement on a single line.
You must use lots of line ends which are othewise known as paragrph markers.
And do a small test to see how hard it is to meet the requirements.
dpb
> @dpb
>
> re: calling from binary file
> An interesting alternative, that I did once consider, however, with
> the large number of times I need to call this code text file
> generation is something i would like to avoid.
Well, the binary file eliminates the text file (which is why I suggested
it) and unless the sizes of the data arrays are _quite_ large, I can't
imagine performance would suffer noticeably, or at least to the point of
being a real bottleneck.
So, the question becomes, just how large of datasets are we talking about?
> As for surpressing the
> output, well that does sound good. I will go over the code later and
> see if the io code splits the task with the output code.
It doesn't matter whether it's separated or not; again that's why I'm
making the suggestion.
The effort required to find the write() statements to the specific file
for the output which you want or don't would be minimal in comparison to
the amount of time I'd imagine you've already spent in trying to read
and convert the code to date.
All you need to do is to either change the current OPEN statement from
formatted write to stream and then replace the
write(unit,fmt) variables
lines w/
write(unit) variables
and you're done.
If it's full arrays and there are currently loops and/or implied-DOs to
format the arrays for the text output it becomes even simpler--just
replace w/ the array name and voila! you've written the entire array (in
column major order, just like Matlab expects).
> As long as I could control the input and have the output going
> straight to an array in matlab that would be adequate.
The above would be an intermediate step but I can't believe it would
really be onerous overhead (see above comment on size).
> Though it would steal my spare time
> reallocation which I gave into the conversion....
I have no idea what this means unless you're saying doing this isn't
converting the whole thing. My point is that unless there's some
inviolate _requirement_ on the application itself being in Matlab, why
do more than is necessary?
> By the By do I need an actual editor for writing fortran....or can I
> use notepad and save it with the correct extension? Notepad opens the
> file and shows no encrypted segments?
No, but you'll certainly do far better with a programmer's editor than a
general text/word processor one. As Gordon says, w/ those tools you
have to make certain you save as text and they have no help. There are
of course endless discussions over good/better/best that are mostly
religious. I use an old DOS no-longer-available one so I'll not mention
any in particular; if you aren't aware at all I'd suggest either a
google or another query of some suggestions from some of the regulars as
I have to admit I know next to nothing about anything in that vein
outside my old copy of Brief.
I'm sure there are many that have language-sensitive features that they
can recommend; Brief does and I've modified the built-in feature macros
fairly extensively over the course of almost 30 years so as long as it
continues to function I'll not be looking elsewhere; in fact given my
essentially retired state I'm sure I'll simply quit rather than switch
if it were ever to come to that (which I don't expect, anyway)... :)
--
dpb
...
> All you need to do is to either change the current OPEN statement from
> formatted write to stream ...
Realize I got sidetracked and didn't mention the "or" side of the
"either"...
Alternatively, if want to keep the existing output for possible human
consumption, add another OPEN to a different iounit for the stream output.
One could then add a flag and some logic around the write() statements
to skip them if not requested for production work yet keep them in the
code unmodified for special use.
The "quick 'n dirty" way would be to simply comment them out, of course,
but I won't mention such an expedient hack here... :)
--
Craig Powers
> By the By do I need an actual editor for writing fortran....or can I
> use notepad and save it with the correct extension? Notepad opens the
> file and shows no encrypted segments?
Any text editor will do, but the better ones will have tools like syntax
highlighting that will make reading and understanding the code easier.
One option to consider is emacs... there is a Windows build available.