Translation problem: portran to MathCad

[ptc-4887948]

Dear mathcad power user

I need to your help and advice for my problem resolve.

I don`t know the Portran languge But My attached portran programming is seems easy.

I have not enough time for earn to portran languge.

Dear Mathcad power user

Please see my attached file and let me know the explain of portran languge structure what is mean.

Or Please let me know the translation to mathcad some of the attached file<portran languge>

And I will try to start of translation for Mathcad.

Best reagards,

Mathcadman <DJ>

[StuartBruff]

A throwback to the good old days of "spaghetti programming", where code can jump to anywhere it wants.

Unless somebody is kind enough and has the time to translate it for you, your best option (should you lack the documentation behind the program) is to draw out the steps in a flowchart.

Anything with "CALL" in front of it is a subroutine and the parameters may be "call by reference" types that will return value in the variable (eg, CALL TEST(X) will compute some value for X and X will have the new value, unlike a "call by value" parameter that will leave X unchanged). In the program "SUKIM9(RCO5,RTIP5,SHITA,SUKIM5)"calls the (external) subroutine SUKIM9 and it appears to return a value for at least SUKIM5 (I haven't checked the rest of the arguments).

AINT and ABS are functions and return the integer part of a value and the absolute value of the input arguments, respectively.

If a name with paretheses appears on the left hand side of an assignment ("="), then the name refers to an array ... looks like origin = 1.

"DO" is the FORTRAN equivalent of "for"; the number after "DO" is the label (the numbers down the left hand side of the program) that marks the end of the loop.

"GO TO <label>" is a command to continue executing the program at the labelled line. Notice that the label can be before the GO TO statement - it's one of the looping mechanisms. It can also allow the program to jump straight out of any level of nested loops. The "CONTINUE" statement doesn't do anything but, appropriately labelled, is often the target of a GO TO and helps indicate the structure (ha ha ha ha ha) of the code.

"IF" is the FORTRAN equivalent of "if", where a number after the "GO TO" again refers to a label. ".NE." means "not equal", ".LE." means "less than or equal", ".LT." measn "less than", similarly with ".EQ.", ".GE." & ".GT." (I haven't checked that they are all used).

Stuart

[RichardJ]

That's some old Fortran! I remember programming in Fortran like that (OK, I just dated myself!). As I recall, if I had to figure out what a program that someone else wrote was doing, I first printed it out (now, I would also have to tape all the pages together, so that it's all on one long piece of paper). Then I would use pens of different colors to draw lines that linked all the GOTOs to the corresponding labels, showed the extent of DO loops, etc. That gives some idea of the program structure. Then I would write all the equations out in normal math notation, next to the corresponding Fortran statement. I might also, as you suggested, have created a flow chart.

Even back then, when I wrote stuff in Fortran, it would have been a lot of work to figure out a program as long as this one, with a high degree of confidence that I had got it right. More than a day, for sure. Now, it would be many days of work. I doubt very much there will be any takers prepared to do this for free.

[StuartBruff]

I used to use a similar method for untangling the code ... if it got 'interesting' then I'd just blank out all of the non-branching code to leave just the 'flow'.

I've just had another glance at the code and this one looks relatively simple. The block between 620 and 640(-1) seems somewhat oddly placed as this is where the program effectively terminates - the conditionals make it loop back to 630 or jump to the final CONTINUE at 660 and the GO TO at line 620(-1) bypasses it. The block between 540 and 620(-1) is self-contained and exits to 640. The block from 640 seems to comprise a couple of simple loops before jumping back to the block at 620. It probably wouldn't take that long to convert it but the big problem, as you say, would be verifying its correctness.

Stuart

[RichardJ]

There is a lot of branching though. It would require some very careful double and even triple checking to make sure that it got translated correctly. One key question in that regard is whether there are one or more known examples, where the output is known for a given input. That would cut the work a lot, because tedious checking would only have to be done if the Mathcad version didn't work correctly.

[RichardJ]

In the 630 block there are two statements that would send it to 660, so why do you think it would end here?

[StuartBruff]

Richard Jackson wrote:

In the 630 block there are two statements that would send it to 660, so why do you think it would end here?

Because I just copied all and pasted special into Mathcad at which point I had an error pop up, Word crashed but the program up to 660 was pasted in ... and I assumed that was all of it. Having reloaded the document, I can see the rest of the pages ... eek!

However, a very quick skim doesn't show up any obviously nasty branches (I note there's at least one computed goto ... Ah, who says nostalgia isn't what it used to be ) and it looks more tedious than difficult - there's one variable called EFFIN and I suspect whoever does the conversion will invoke the name of this variable on more than one occasion.

Stuart

[RichardJ]

it looks more tedious than difficult

I agree.

there's one variable called EFFIN and I suspect whoever does the conversion will invoke the name of this variable on more than one occasion.

I agree with that too

[ValeryOchkov]

About Portran, sorry, Fortran:

"Imagine a firm, a corporation, or a university that have developed and collected a wide range of programs (in Fortran, for example) for 30-40 years: with different degree of complexity, for calculation or simulation broad-ranging processes, mechanisms, and techniques in various sciences and technologies, for database development and management. New computers with new operating systems are being substituted for worn out and outdated equipment. Computers are being joined the local networks, which, in turn, don’t keep out of ― globalization‖ and are being connected to the Internet. As a result of computer modernization, old applications often don’t launch in the new or upgrade workstation computers and servers. Sometimes it is impossible to read a program from a media (a punched card, a punched tape, various floppies) because the new computers have no relevant readout devices. Such programs are rejected or people spend time and finances to buy or develop a utility (an emulator) to launch them. But it’s not so very serious. The problem is that the specialists who developed these programs leave ― a firm, a corporation, or a university‖ and the new, younger ones can’t upgrade or adapt the applications. The reasons are insufficient code documenting, lack of appropriate development software, and just inability to read the program written in an outdated (dead) language. Even if a programmer manage to recreate or upgrade an old application with great difficulty using an old or a new programmer language, codes, which only programmers can understand, ― a nightmare of the inherited software‖ would appear again later."

See the full article here

[tdevaraj]

Valery, very nice article!.

I have seen examples of FORTRAN, whereby the inquirer was attempting re-write the code as was in the FORTRAN environment using a line-by-line intepretation to Mathcad. Very quickly it transpired that, sometimes its not about the code itself, rather the problem the code was written to solve. There are many new effiicent ways/tools out there designed to help achieving what the FORTRAN code was written to do...in this case recreating physical geometry for analysis (stress,fatigue). You could have argued that in this case even the choice of Mathcad was questionable given the solid modelling tools and FE tools in the market today.

Fortunately (or not) I have not had the pleasure of having to re-interprate someone elses FORTRAN program.

But it certainly seems to be a dying art/skill.

[ValeryOchkov]

Thomas Devaraj wrote:

Valery, very nice article!.

Thanks, but the english is not good.

Can you edit this translation, please, and may by edd something...

I have publis this article in Russian (http://twt.mpei.ac.ru/ochkov/SLD-09-08-Ochkov.pdf)

and would like to publish in english. I have a jourlal for it.

And second

Mathcad has no lables but Mathcad MM and Mathcad Prime Minister have - see http://communities.ptc.com/docs/DOC-2161

For Fortran-Mathcad translation!

and 3-d - for Russian readerы about Portran - Fortran.

Стоит у памятника Пушкину человек и восхищается: "О! Кушкин! О! Кушкин!"

Прохожий говорит: "Товарищ, это Пушкин, а не Кушкин!"

Ему отвечают: "Кашел отсуда!"

[MichaelH]

It would probably be easier if you just figure out what the FORTRAN program is supposed to do and then simply write it in Mathcad.

I doubt if anyone here has the time or energy to translate that unstructured spaghetti code for free.

[RichardJ]

It would probably be easier if you just figure out what the FORTRAN program is supposed to do and then simply write it in Mathcad.

That's a very good point. It's quite likely that the best way to do it in Mathcad would not just be translation of the Fortran anyway.

[StuartBruff]

Richard Jackson wrote:

It would probably be easier if you just figure out what the FORTRAN program is supposed to do and then simply write it in Mathcad.

That's a very good point. It's quite likely that the best way to do it in Mathcad would not just be translation of the Fortran anyway.

That might be the better option IF the detail is available to support an analysis ... figuring out what the code is doing structurally doesn't necessarily lead to sufficient understanding of what the underlying algorithm is supposed to do and it might be much simpler to take a 'monkey see, monkey do' approach.

Stuart

[ViacheslavMezen]

You need to run individual parts of the fortran program and see what they do. For these purposes it is necessary to have a working template. Here is an example of this template - a user efi library (dll) for Mathcad:

https://smath.info/svn/public/plugins/mcadefi/TestFortran/

Tools:

1. Intel(R) Visual Fortran Compiler XE 12.0.1.127 [IA-32]

2. MSVS2008 / MSVS2010

You have to learn Fortran, to understand how it works. After that you can use your Fortran program directly from Mathcad. In any case it is not a simple task.

[ValeryOchkov]

In main part of same cases (fortran-Pascal, fortran-C, fortran-Mathcad etc.) it is more simple to use not fortran code but origin problem description.

[ViacheslavMezen]

Are you sure? That's exactly the same example and description. The task - rewrite in Delphi. I think that the interface is easier to do in Delphi, and leave program in a Fortran as an external dll.