"E.D.G." <edgrs...@ix.netcom.com> writes: > "E.D.G." <edgrs...@ix.netcom.com> wrote in message > news:jckdnqiu1zxguxvpnz2dnuvz_qmdn...@earthlink.com... >> "E.D.G." <edgrs...@ix.netcom.com> wrote in message >> news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@earthlink.com... > > Etgtab FORTRAN project > Perl speed comparison > > This Etgtab FORTRAN computer program related effort is > progressing much better than I thought possible. Here is some > information on the project plus a status report. > > The Etgtab program appears to be highly unique. And under the > right conditions it might be highly valuable to the international > scientific community. So, what we are attempting to do is get it > translated into some modern language that researchers around the world > can have their own programmers easily modify for their specific uses. > > > The first step is to get someone to actually prepare the new > code. And if it were up to me I would stay with FORTRAN. > > It appears that my retired programming colleague is going to be > willing to do the work since he has the program already partly > translated. But he will only prepare a True BASIC translation.
There is a slight air in unreality to all this, but just in case this is a real project, here are a few random observations. Fortran is still the language that most scientists use, and the program is already a working Fortran program. The most significant thing you could do to revive this work is to document it and tidy up the code. If you wan to modernise the code (and there could be benefits in terms of clarity if you do so) a modern version of standard Fortran is the obvious choice. However, a few well-written pages explaining what the program does and how it does it, together with some more detailed descriptions of the algorithms will probably be more beneficial than any updating, especially if you can find references to papers describing the original work. Though to my mind secondary, tidying up the code would also help. Things could be clarified by introducing a few more utility functions, using more descriptive names, indenting loops, replacing out-dated constructs with newer ones, and so on. These two things will make the program far more accessible to the scientific community. Translating it into a proprietary (paid for) implementation of Basic will ensure that no one ever uses it again. True BASIC does not even have a Linux/Unix port. Finally, why are you timing Perl arithmetic? A translation into Perl does not seem to be an option. <snip> -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
