Fortran - Fortran is eating my brain

Author

Fortran is eating my brain

qqcq6s59@gmail.com

2005-09-23, 7:00 pm

Hi All fortran experts,

Last few years of my life i have learned many languages (otherthan
fortran and I am a scientist/Er!!!) but never used few.

Nowadays i use perl python tcl etc for creating traslating and parsers
(thats waht my requirement so I thin they doest the work better) few
days back I have come across a problem where I need to translate a
output file from oneEng apllication to another Eng application, the
first one writes the output file using fortran units wither in UNFMTD
binary or formatted text.

The strange things I noticed is the TEXT file isn`t a text file, and
creating a perl or python program to parse file looks like a tough
task. So I started learning Fortran but it really kicks my ....

can you guys give me a good book which explains nealtly all these I/O
stuff.
If possible can some one give me some info on why the fortran is so
different and what are the essential basics.

Ifeel I am better to start with a good book, meantime if you guys can
give me some info, i would be thankfull.

Sorry if my post contains typos, i am using otherthan english funny and
keybord.

-jiro

Gordon Sande

2005-09-23, 7:00 pm

On 2005-09-23 12:47:13 -0300, qqcq6s59@gmail.com said:

> Hi All fortran experts,
>
> Last few years of my life i have learned many languages (otherthan
> fortran and I am a scientist/Er!!!) but never used few.
>
> Nowadays i use perl python tcl etc for creating traslating and parsers
> (thats waht my requirement so I thin they doest the work better) few
> days back I have come across a problem where I need to translate a
> output file from oneEng apllication to another Eng application, the
> first one writes the output file using fortran units wither in UNFMTD
> binary or formatted text.
>
> The strange things I noticed is the TEXT file isn`t a text file, and
> creating a perl or python program to parse file looks like a tough
> task. So I started learning Fortran but it really kicks my ....

For some applications TEXT is a funny spelling of DATA usually to
tell data from metadata and the metadata is then called DATA so
you have to read the various manuals. Nothing unique about Fortran
there. Program loaders are an immediate example of this termonology
shift.

Strict Fortran terminology has "unformatted" for data which is in the
native machine's format. Clearest examples are with floating point.
Think binary.

Fortran terminology for human legible converted data is "formatted".
Once upon a time formatted data was only available if you used a
FORMAT but then a variety of ways for having the system use some
format, of its convenience, arrived. These convenient methods are
called "list directed" but many too many times are said to be
unformatted as a sloppy way of saying that no explicit FORMAT
was given by the user. So you have to bring your lawyer and question
whoever is supplying the data closely to figure out which meaning
of unformatted is intended. It is a bummer!

If the data is "formatted" then it should be human legible and you
should be able to parse it.

If it is "unformatted" then be aware that Fortran uses a record oriented
data model. This allows easy forward skipping and backspacing. Things
that the byte stream data model users woulld never even guess might be
needed or useful. But the record oriented data model needs to know
record lengths so there is typically a length count at the front and
end of every "unformatted" record. Details are in the vendor's manual
as to whether the length is 4 or 8 bytes and whether records are
spanned to keep within some maximum and other such critical facts
that are not seen by the user. Reading records as byte streams
requires that you know these critical facts.

Some Fortran implementaions, now all as of F2003, have some ability to
deal with byte streams. Once again you need your lawyer friend to ferret
out the details if the provider is at all

or careless with
precise details.

You problems sound like poor use of technical terms with different
meanings in different contexts. Trying to sort things out when the data
involved is character data may make the problem worse as both humans
and machines like the same stuff. If you have a funny non English
keyboard then the chances for bad translations increase to between
languages as well as between contexts.

> can you guys give me a good book which explains nealtly all these I/O
> stuff.
> If possible can some one give me some info on why the fortran is so
> different and what are the essential basics.
>
> Ifeel I am better to start with a good book, meantime if you guys can
> give me some info, i would be thankfull.
>
> Sorry if my post contains typos, i am using otherthan english funny and
> keybord.
>
> -jiro

qqcq6s59@gmail.com

2005-09-24, 3:56 am

Thanks a lot Gordon Sande
Thanks for your detailed info, I could understand it.

>If the data is "formatted" then it should be human legible and you
>should be able to parse it.
It is a compressed Text file, they vendor claim it, so I can open it in
text editor but I couldnt able to figure out myself,
I understood that I need to know the details of the format in which the
Application writes this file to parse it,

To make things worse, I work in a non-English speaking country.
where I have virtually no support from IT department (I should learn
their language)
I cant even use manuals, not even man command in unix terminal.
I am not complaining but it just make me work harder to solve even a
simple problem.

I somehow try to get my vendor info...

Thanks again
-jiro

Gordon Sande

2005-09-24, 6:58 pm

On 2005-09-24 02:49:23 -0300, qqcq6s59@gmail.com said:

> Thanks a lot Gordon Sande
> Thanks for your detailed info, I could understand it.
>
>
> It is a compressed Text file, they vendor claim it, so I can open it in
> text editor but I couldnt able to figure out myself,
> I understood that I need to know the details of the format in which the
> Application writes this file to parse it,

From your description I would guess that the Fortran program is calling
someone's library which compresses the text before writing it out. If
that is the case then you need the name of the library and its documentation
to figure out what is being sent to the outside world. Your problem
would be the same for all languages which could call such a library.
They may even be bypassing the Fortran i/o system!

If it is just text that has been sent to a zip or compress library then
you might try using an unzip or uncompress utility to get the text
which might then be clear. There are such libraries so this might be
a possibility. Hope that the vendor used something that already existed
and was in common use. Otherwise you may end up buying a few beers
for someone who knows cryptography. ;-) Foriegn languages are
easier after a few beers!

> To make things worse, I work in a non-English speaking country.
> where I have virtually no support from IT department (I should learn
> their language)
> I cant even use manuals, not even man command in unix terminal.
> I am not complaining but it just make me work harder to solve even a
> simple problem.
>
> I somehow try to get my vendor info...

Yes! Yes! See above.

> Thanks again
> -jiro

Sponsored Links