FAQ
Posted by E.D.G. on November 14, 2013


        In view of the fact that I mentioned the following project in both
Perl and Python Newsgroup notes and did not get any hostile responses I am
going to take a chance and mention it again in all three of these
Newsgroups. People posting responses might want to do that in just one
Newsgroup. I will check all three for responses for a few weeks.




        This is the Web address for an interesting and apparently unique
computer program written using FORTRAN 77. As far as I am aware, it has
never been translated to newer language. There is a BASIC version that was
apparently written around the same time as the FORTRAN version.


http://www.bfo.geophys.uni-stuttgart.de/etgtab.html


        What a number of us would like to do is obtain a copy of the program
that is written in a newer language so that we can then merge it with the
programs available through the following Web page. The new programs would
then be made available as freeware programs to researchers around the world.
This indirect link is being used in an effort to keep Web site related spam
to a minimum. I don't collect credits by having people visit that
(indirect) Web site.


http://www.freewebs.com/eq-forecasting/RH.html


        If there are any programmers who might be interested in such a
translation effort then I would be interested in hearing from them.


        Etgtab generates Solid Earth Tide and ocean tide data for any
location on or inside the planet. I am not aware of any other freeware
program that can do that.


        SunGP available at that second Web site is the only freeware program
that I know about that generates what are sometimes referred to as subsolar
and sublunar types of data. The download code was written using True BASIC.


        If you draw a line between the centers of the sun and the Earth then
the place where that line crosses the surface of the Earth is the subsolar
location. The sublunar location is the same type of thing. The SunGP
program code is also available in Perl code, but not through any Web sites.

Search Discussions

  • Mecej4 at Nov 14, 2013 at 5:07 pm

    On 11/14/2013 8:18 AM, E.D.G. wrote:
    Posted by E.D.G. on November 14, 2013

    In view of the fact that I mentioned the following project in
    both Perl and Python Newsgroup notes and did not get any hostile
    responses I am going to take a chance and mention it again in all three
    of these Newsgroups. People posting responses might want to do that in
    just one Newsgroup. I will check all three for responses for a few weeks.


    This is the Web address for an interesting and apparently unique
    computer program written using FORTRAN 77. As far as I am aware, it has
    never been translated to newer language. There is a BASIC version that
    was apparently written around the same time as the FORTRAN version.

    http://www.bfo.geophys.uni-stuttgart.de/etgtab.html

    What a number of us would like to do is obtain a copy of the
    program that is written in a newer language so that we can then merge it
    with the programs available through the following Web page. The new
    programs would then be made available as freeware programs to
    researchers around the world. This indirect link is being used in an
    effort to keep Web site related spam to a minimum. I don't collect
    credits by having people visit that (indirect) Web site.

    http://www.freewebs.com/eq-forecasting/RH.html

    If there are any programmers who might be interested in such a
    translation effort then I would be interested in hearing from them.

    Etgtab generates Solid Earth Tide and ocean tide data for any
    location on or inside the planet. I am not aware of any other freeware
    program that can do that.

    SunGP available at that second Web site is the only freeware
    program that I know about that generates what are sometimes referred to
    as subsolar and sublunar types of data. The download code was written
    using True BASIC.

    If you draw a line between the centers of the sun and the Earth
    then the place where that line crosses the surface of the Earth is the
    subsolar location. The sublunar location is the same type of thing.
    The SunGP program code is also available in Perl code, but not through
    any Web sites.
    If this old program is to be translated or reused, do use this
    opportunity to fix some bugs in the program.


    The data file contains data for 1200 waves, but the program computes
    results for 1212 waves. For waves 1201 to 1212, the program ends up
    calculating results based on uninitialized data. Whether or not this
    affects the validity of the final output results is something that
    someone knowledgeable about the field of application has to judge.


    -- mecej4
  • Gordon Sande at Nov 14, 2013 at 5:36 pm

    On 2013-11-14 17:07:45 +0000, mecej4 said:

    On 11/14/2013 8:18 AM, E.D.G. wrote:
    Posted by E.D.G. on November 14, 2013

    In view of the fact that I mentioned the following project in
    both Perl and Python Newsgroup notes and did not get any hostile
    responses I am going to take a chance and mention it again in all three
    of these Newsgroups. People posting responses might want to do that in
    just one Newsgroup. I will check all three for responses for a few weeks.


    This is the Web address for an interesting and apparently unique
    computer program written using FORTRAN 77. As far as I am aware, it has
    never been translated to newer language. There is a BASIC version that
    was apparently written around the same time as the FORTRAN version.

    http://www.bfo.geophys.uni-stuttgart.de/etgtab.html

    What a number of us would like to do is obtain a copy of the
    program that is written in a newer language so that we can then merge it
    with the programs available through the following Web page. The new
    programs would then be made available as freeware programs to
    researchers around the world. This indirect link is being used in an
    effort to keep Web site related spam to a minimum. I don't collect
    credits by having people visit that (indirect) Web site.

    http://www.freewebs.com/eq-forecasting/RH.html

    If there are any programmers who might be interested in such a
    translation effort then I would be interested in hearing from them.

    Etgtab generates Solid Earth Tide and ocean tide data for any
    location on or inside the planet. I am not aware of any other freeware
    program that can do that.

    SunGP available at that second Web site is the only freeware
    program that I know about that generates what are sometimes referred to
    as subsolar and sublunar types of data. The download code was written
    using True BASIC.

    If you draw a line between the centers of the sun and the Earth
    then the place where that line crosses the surface of the Earth is the
    subsolar location. The sublunar location is the same type of thing.
    The SunGP program code is also available in Perl code, but not through
    any Web sites.
    If this old program is to be translated or reused, do use this
    opportunity to fix some bugs in the program.

    The data file contains data for 1200 waves, but the program computes
    results for 1212 waves. For waves 1201 to 1212, the program ends up
    calculating results based on uninitialized data. Whether or not this
    affects the validity of the final output results is something that
    someone knowledgeable about the field of application has to judge.

    -- mecej4

    Indeed! Under NAGWare Fortran it runs to completion with C=all but pulls an
    undefined reference when C=undefined is added.


    Lots of obsolete features and other warnings but no compiler error messages.


    The obvious lessons are that 1. Fortran has very good historical continuity
    and 2. the good debugging Fortran compilers do a good job.
  • Clive Page at Nov 15, 2013 at 11:46 am

    On 14/11/2013 17:36, Gordon Sande wrote:


    Indeed! Under NAGWare Fortran it runs to completion with C=all but pulls an
    undefined reference when C=undefined is added.

    Lots of obsolete features and other warnings but no compiler error
    messages.

    The obvious lessons are that 1. Fortran has very good historical continuity
    and 2. the good debugging Fortran compilers do a good job.

    I would also check it out with FTNCHEK as well - it usually finds lots
    of potential or actual problems with code of this vintage.




    --
    Clive Page
  • Jürgen Exner at Nov 17, 2013 at 5:02 pm

    mecej4 wrote:
    On 11/14/2013 8:18 AM, E.D.G. wrote:
    Posted by E.D.G. on November 14, 2013

    In view of the fact that I mentioned the following project in
    both Perl and Python Newsgroup notes and did not get any hostile
    responses [...]

    Don't flatter yourself. Just to get the records straight: you didn't get
    any replies because any- and everyone in CLPM has plonked you aeons ago.


    jue
  • E.D.G. at Nov 15, 2013 at 1:51 pm
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...


            The responses regarding that Etgtab program were encouraging. I was
    not sure if anyone would even recognize the code as the program was written
    quite a while ago.


            The main reason for wanting to translate it into modern language code
    is so that it can be easily modified and also merged with another computer
    program. The main language it would probably be translated into is True
    BASIC. This is because the person doing the work is a retired professional
    computer programmer who does work like that as a hobby. But he will only
    work with True BASIC. In fact he already translated most of the Etgtab
    program. The effort got stopped when he could not understand some of the
    FORTRAN code. Unlike working personnel, retired people can start and stop
    efforts like that as they please.


            From discussions with people in several Newsgroups the conclusions I
    arrived at in the past few weeks are the following:


            Perl would not work because it does calculations too slowly.
    Standard Python would also not work for the same reason. However, there are
    Python routines available that would make it possible to accelerate the
    calculations.


            FORTRAN, True BASIC, XBasic, and another language called Julia likely
    do calculations fast enough. Julia looks like it is specifically designed
    for that type of work.


    http://julialang.org/


            I am checking with that programmer to see if he wants to continue
    with the effort.


            The program itself has some importance for earthquake related
    research. A number of years ago I checked with the U.S. Government's "Ask A
    Geologist" staff to see if they knew about any freeware programs that
    researchers could use to generate those types of data. And I was told that
    they did not know of any. Apparently they did not even know that Etgtab
    exists. I had to do some Internet searches to find it.


            The Solid Earth Tide data it generates are probably fairly good. The
    plan is to check its ocean tide data against data from the following Web
    site to see how well they match.


    http://tbone.biol.sc.edu/tide/


            We could not find any good freeware programs for generating the types
    of sun and moon location data needed for this research and so we wrote one
    ourselves. It has been available for a number of years as a freeware
    program written in True BASIC.
  • E.D.G. at Nov 17, 2013 at 10:25 am
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:jcKdnQiu1ZxguxvPnZ2dnUVZ_qmdnZ2d at earthlink.com...
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at 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.


            In order for him to finish the True BASIC version we would need a
    modern FORTRAN version of the program that my research colleague can
    decipher. And it appears that there are some people or groups that are
    willing to help make that conversion. He can hopefully work with them to
    get any details settled.




            We would then like to merge that True BASIC version of program with
    an already existing True BASIC program and then get things organized so that
    the output data can be displayed on charts.


            Personally, I don't like the way that True BASIC draws charts for
    Windows computers. And although my colleague has permission to put chart
    drawing routines in the program we also plan to use a different procedure.
    I myself will create a Perl language program that can call an exe version of
    the True BASIC program and have it generate the necessary data. Perl can
    then plot the data on a chart. That doesn't take long.


            We will then make those Perl chart generation code available to the
    Python programmers and any other interested parties to see if they would
    like to create a Python (or whatever) program that can do the same thing.


            Of course, everything could be done using FORTRAN. However since
    this is all volunteer work we need to go with whatever language the people
    actually doing the work are willing to work with.




    PERL SPEED COMPARISON


            Some of the early discussions leading to this point involved
    calculation speed comparisons for Perl and Python. The table on the
    following Web page contains some interesting speed comparisons between
    various programming languages. They are all compared to the speed it takes
    a "C" language program to run the tests.


    http://julialang.org/


            For comparing Perl with Perl I ran the following program. And I
    would expect that the same time differences might also be seen if standard
    Python were used though each individual speed might run faster than Perl.


    print 'start', "\n";
          for (1..100000000){$x = 2/3};
    print 'end', "\n";
    sleep 10;


    8 seconds - On a 64 bit Windows 8 fast quad core 64 bit computer with plenty
    of memory running the latest version of ActiveState 64 bit Perl there was an
    8 second delay between when it printed "start" and "end."


    20 seconds - On a 32 bit Vista fairly fast dual core 64 bit computer with
    plenty of memory running ActiveState 32 bit Perl 5.10.0.1005 there was a 20
    second delay between the "start" and "end."


    36 seconds- On a 32 bit XP moderate speed single core computer (don't know
    if it is 32 or 64 bit) using a software program that makes it work like a
    dual core system plus plenty of memory running ActiveState 32 bit Perl
    5.10.0.1005 there was a 36 second delay between "start" and "end."
  • Ben Bacarisse at Nov 17, 2013 at 12:45 pm

    "E.D.G." <edgrsprj@ix.netcom.com> writes:


    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:jcKdnQiu1ZxguxvPnZ2dnUVZ_qmdnZ2d at earthlink.com...
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at 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.
  • E.D.G. at Nov 17, 2013 at 2:37 pm
    "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
    news:0.444ab0f1470c9d9a7a89.20131117124526GMT.87li0nqjrt.fsf at bsb.me.uk...

    There is a slight air in unreality to all this, but just in case this is

            The world of science where programmers work with people who have
    degrees in the physical sciences can get complicated. I myself have found
    that it is almost a necessity to have people sitting next to one another in
    order to get anything done in a timely manner. A relatively simple program
    that my programming colleague and I developed took something like six months
    to get running because it was created by sending E-mail back and forth. And
    virus filters etc. kept blocking some of the programs. We had to give them
    all dat extensions just to send them from one location to another and then
    change them back to exe or zip at their destinations.



    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.

            I myself would go with Fortran. But my programming colleague will
    only work with True BASIC. And he is the one who will be doing the work.
    Fortunately, it sounds like there is a Fortran to True BASIC converter
    avaiable. So, once underway the effort might be completed in a very short
    time.



    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.

            For one thing, the input and output routines need to be changed. And
    we want it to be able to generate charts or graphs. The existing program
    will generate only text data.


            If it is translated to True BASIC then those code along with the
    newer Fortran code will likely be made available to people as freeware.



    Finally, why are you timing Perl arithmetic? A translation into Perl

            Those timing data were an update for earlier notes that were posted
    to the Perl and Python Newsgroups. One question that got asked was if 64
    bit Perl runs faster than 32 bit Perl for simple math. Those speed tests
    indicate that there was only about a factor of 2 difference at best.


            All of my own important programs are written using Perl. I am
    starting to run into calculation speed limitations with one of the programs.
    And I wanted to determine if the calculations could be done faster within
    Perl or if another language would need to be used. The answer is that for
    math calculations there are much faster languages including Fortran.


    These are personal opinions.
  • Henry Law at Nov 17, 2013 at 2:42 pm

    On 17/11/13 14:37, E.D.G. wrote:
    All of my own important programs are written using Perl. I am starting
    to run into calculation speed limitations with one of the programs.

    Your Perl code is, er, sub-optimal. There is absolutely no point in
    doing benchmarks until you've improved the code.


    I've got an idea; why not re-write it all in C?


    --


    Henry Law Manchester, England
  • Roy Smith at Nov 17, 2013 at 3:20 pm
    In article <xmydnrjrq45fsbxpnz2dnuvz8mgdnz2d@giganews.com>,
      Henry Law wrote:

    On 17/11/13 14:37, E.D.G. wrote:
    All of my own important programs are written using Perl. I am starting
    to run into calculation speed limitations with one of the programs.
    Your Perl code is, er, sub-optimal. There is absolutely no point in
    doing benchmarks until you've improved the code.

    Having spent many years in science (molecular biology), I disagree with
    this sentiment.


    Scientists view computer programs as tools, no different from any other
    piece of lab equipment or instrumentation they use. When picking a tool
    to use, it's perfectly reasonable to evaluate what performance you can
    get out of that without having to be an expert in its use. If I'm using
    a spectrophotometer, there may be many things that instrument is capable
    of doing, but as long as I'm getting the data I need from it, it's
    serving my purpose. My goal is to do science, not to be an expert on
    optics, or electronics, or data processing.


    The same goes for programming languages. Most programs I've seen
    written by scientists are horrible from a computer science point of
    view, but they serve their purpose. A language which makes is easy for
    a non-(computer)-expert to write decent programs is a good tool.


    To get back to the original point, let's say I (as a computer expert) am
    comparing two programming languages, L1 and L2. If I write a fully
    optimized program in L1 and a piece of crap in L2, then try to say, "L1
    is better than L2", that's a poor comparison. Until I've optimized my
    L2 code, it is, as Henry says, pointless to try to compare them.


    But, for a non-expert, it may be that while L2 is capable of computing a
    solution in less time than L1, it takes a lot of expert knowledge to get
    the L2 program to that state. For the limited amount of programming
    expertise and time available, L1 may actually be better for this use
    case.
  • Chris Angelico at Nov 17, 2013 at 3:28 pm

    On Mon, Nov 18, 2013 at 2:20 AM, Roy Smith wrote:
    But, for a non-expert, it may be that while L2 is capable of computing a
    solution in less time than L1, it takes a lot of expert knowledge to get
    the L2 program to that state. For the limited amount of programming
    expertise and time available, L1 may actually be better for this use
    case.

    But then you have to be careful how you describe your conclusion. You
    can't say that Python is a faster language than C on the basis that
    it's quicker to get a working Python program than a working C program.
    However, I do agree with your sentiment.


    ChrisA
  • E.D.G. at Nov 17, 2013 at 4:25 pm
    "Roy Smith" <roy@panix.com> wrote in message
    news:roy-D4B9A4.10202517112013 at news.panix.com...

    Scientists view computer programs as tools, no different from any other

            I agree totally. There are many scientists who learn how to write
    programs to help with their scientific work. I doubt that there are too
    many programmers who go out and get an additional degree in biology,
    chemistry, or physics to help with their programming work. And there
    appears to me to often be a gap between how people in the two different
    worlds go about getting things done.


            Since this program translation will be done by someone who actually
    wrote program code for a living it will at least actually look like a
    program when it is finished. There will be indentation etc.
  • Tim Prince at Nov 17, 2013 at 4:30 pm

    On 11/17/2013 8:25 AM, E.D.G. wrote:
    "Roy Smith" <roy@panix.com> wrote in message
    news:roy-D4B9A4.10202517112013 at news.panix.com...
    Scientists view computer programs as tools, no different from any other
    I agree totally. There are many scientists who learn how to
    write programs to help with their scientific work. I doubt that there
    are too many programmers who go out and get an additional degree in
    biology, chemistry, or physics to help with their programming work. And
    there appears to me to often be a gap between how people in the two
    different worlds go about getting things done.

    Since this program translation will be done by someone who
    actually wrote program code for a living it will at least actually look
    like a program when it is finished. There will be indentation etc.
    Perhaps you would start with an automatic indentation tool before
    translating. You may have a rule against using current syntax and
    indentation for Fortran, but others don't.


    --
    Tim Prince
  • Roy Smith at Nov 17, 2013 at 4:43 pm
    In article <bes9a5ffm6du1@mid.individual.net>,
      Tim Prince wrote:

    Perhaps you would start with an automatic indentation tool before
    translating. You may have a rule against using current syntax and
    indentation for Fortran, but others don't.

    Does anybody still use ratfor?
  • Richard Maine at Nov 17, 2013 at 5:05 pm

    Roy Smith wrote:


    In article <bes9a5ffm6du1@mid.individual.net>,
    Tim Prince wrote:
    Perhaps you would start with an automatic indentation tool before
    translating. You may have a rule against using current syntax and
    indentation for Fortran, but others don't.
    Does anybody still use ratfor?

    No. Well, I suppose it is possible you might find a soul or two
    somewhere, but you'd have to look prety hard. Ratfor became essentially
    obsolete with Fortran 77.


    --
    Richard Maine
    email: last name at domain . net
    domain: summer-triangle
  • Joel Goldstick at Nov 17, 2013 at 5:29 pm

    On Sun, Nov 17, 2013 at 12:05 PM, Richard Maine wrote:
    Roy Smith wrote:
    In article <bes9a5ffm6du1@mid.individual.net>,
    Tim Prince wrote:
    Perhaps you would start with an automatic indentation tool before
    translating. You may have a rule against using current syntax and
    indentation for Fortran, but others don't.
    Does anybody still use ratfor?
    No. Well, I suppose it is possible you might find a soul or two
    somewhere, but you'd have to look prety hard. Ratfor became essentially
    obsolete with Fortran 77.

    --
    Richard Maine
    email: last name at domain . net
    domain: summer-triangle
    --
    https://mail.python.org/mailman/listinfo/python-list

    This thread is bizarre. Its been over 20 years since I have heard the
    term 'freeware'. The OP first seems to suggest that he wants to
    translate this code to python or some other language. He then points
    out that the guy they have doing the re-write will only write it in
    True BASIC. I'm not seeing how this has anything to do with python,
    except that there was mention that it wouldn't be fast enough. Is
    True BASIC fast?


    That being said, I'm guessing that this thing is used in some academic
    setting. If that's true, why not get a student (who will be much more
    versed in modern programming languages and techniques) to document and
    rewrite the code. When you start off with the requirement that the
    new code will be True BASIC you may find that it serves your purposes,
    but over time no one will know what to make of the code since no one
    learns BASIC (or FORTRAN) anymore I don't think


    --
    Joel Goldstick
    http://joelgoldstick.com
  • E.D.G. at Nov 18, 2013 at 5:30 pm
    "Joel Goldstick" <joel.goldstick@gmail.com> wrote in message
    news:mailman.2792.1384709379.18130.python-list at python.org...


    That being said, I'm guessing that this thing is used in some academic
    setting. If that's true, why not get a student (who will be much more
    versed in modern programming languages and techniques) to document and
    rewrite the code. When you start off with the requirement that the

            True BASIC appears to do calculations at a speed that is probably
    somewhere in the Fortran range. And as I stated, since someone volunteered
    to do some modernization work he gets to select whatever language he
    prefers. Also as I stated, I am now starting some discussions with
    scientists who actually use these types of data on a regular basis in order
    to get some input from them. Perhaps they might want to have some of their
    own programmers modernize the code.
  • Rainer Weikusat at Nov 17, 2013 at 6:59 pm

    Roy Smith <roy@panix.com> writes:
    Henry Law wrote:
    On 17/11/13 14:37, E.D.G. wrote:
    All of my own important programs are written using Perl. I am starting
    to run into calculation speed limitations with one of the programs.
    Your Perl code is, er, sub-optimal. There is absolutely no point in
    doing benchmarks until you've improved the code.
    Having spent many years in science (molecular biology), I disagree with
    this sentiment.

    Scientists view computer programs as tools, no different from any other
    piece of lab equipment or instrumentation they use. When picking a tool
    to use, it's perfectly reasonable to evaluate what performance you can
    get out of that without having to be an expert in its use. If I'm using
    a spectrophotometer, there may be many things that instrument is capable
    of doing, but as long as I'm getting the data I need from it, it's
    serving my purpose. My goal is to do science, not to be an expert on
    optics, or electronics, or data processing.

    The same goes for programming languages.

    Indeed it does. So, while your comfortable with BUYING spectrophotometers
    built by people who know how to do that, why on earth do you insist on
    hacking your own 'Rocky Horror Picture Show' crap code together to
    evaluate the data INSTEAD of concentrating on 'the science'?
  • James Van Buskirk at Nov 17, 2013 at 4:05 pm
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:F7mdndYtY6YrSRXPnZ2dnUVZ_oWdnZ2d at earthlink.com...

    For one thing, the input and output routines need to be changed.
    And we want it to be able to generate charts or graphs. The existing
    program will generate only text data.

    You can generate charts and graphs in Fortran. Just use OpenGL via
    f2003 C interoperability. One project that does this is f03GL.
    Another project interfaces to GTK (gtk-fortran).


    --
    write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
    6.0134700243160014d-154/),(/'x'/)); end
  • Charlton Wilbur at Nov 18, 2013 at 4:22 am
    "BB" == Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

         BB> There is a slight air in unreality to all this,


    This is a far more polite way of putting it than I would. It's an
    earthquake predictor based on pseudoscience and technobabble.


         BB> Finally, why are you timing Perl arithmetic? A translation into
         BB> Perl does not seem to be an option.


    EDG has been trying ineffectually to get this suite of programs to work,
    integrating them with gnuplot and a Perl web application, for as long as
    I can remember. I suspect years ago someone told him that Perl was the
    One True Language for web applications and the evidence of the
    intervening decade has not been enough to convince him otherwise.


    Followups set to comp.lang.perl.misc; c.l.python and c.l.fortran have
    enough crazy overlap from c.l.p.m without adding me to the mix.


    Charlton




    --
    Charlton Wilbur
    cwilbur at chromatico.net
  • E.D.G. at Nov 17, 2013 at 4:17 pm

    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...

            All of the necessary information regarding this effort has now been
    obtained. So, further discussions of this particular project will probably
    take place in only the Fortran Newsgroup. If and when the project is
    completed I will probably post another general note about it.


            The retired computer programmer that I am working with has agreed to
    work on it. If we can generate a modern Fortran translation of the original
    program code then that will be made available to people and probably tested
    by Fortran users. And researchers around the world can then work with that
    code if they wish. But, if my programming colleague is going to do any work
    on modifying the newer program code then that will need to be done using
    True BASIC as that is the only language he will work with. So, for our own
    work, its that language or nothing.


            The project is in my opinion worthwhile as the Etgtab program seems
    to be so unique. No other freeware program can generate those data as far
    as I am aware. And it has been my own experience that True BASIC code is
    very easy to translate into virtually any other language.
  • E.D.G. at Nov 17, 2013 at 6:07 pm

    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...

            Some additional research indicates that there is an international
    scientific organization that should be interested in this particular program
    translation effort. And tomorrow I plan to contact them and see what they
    have to say about it. It is possible they might decide to do the work
    themselves.
  • Terry Reedy at Nov 18, 2013 at 3:28 am
    On 11/17/2013 5:25 AM, E.D.G. wrote:
    [snip several paragraphs that have nothing to do with Python]


    A couple of sentences of follow-up would have been sufficient.


    'We decided to go with Fortran and True-Basic and not Python."

    PERL SPEED COMPARISON

    Some of the early discussions leading to this point involved
    calculation speed comparisons for Perl and Python. The table on the
    following Web page contains some interesting speed comparisons between
    various programming languages. They are all compared to the speed it
    takes a "C" language program to run the tests.

    http://julialang.org/

    [snip discussion of perl that is off-topic for python-list]






    --
    Terry Jan Reedy
  • E.D.G. at Nov 18, 2013 at 5:15 pm
    "Terry Reedy" <tjreedy@udel.edu> wrote in message
    news:mailman.2820.1384745298.18130.python-list at python.org...

    A couple of sentences of follow-up would have been sufficient.

            The experience that I have had over the years with Newsgroup posting
    is that it is generally better to try to be polite and answer as many
    questions as possible even when that results in more information being
    posted than might be necessary. Hopefully a discussion will then end
    quietly on a pleasant note.


            That approach seems to usually produce good results. Quite often
    people who are happy with the tone of the public Newsgroup discussion will
    send along some valuable information by E-mail. And that has been happening
    with this present discussion that will now continue in only the Fortran
    Newsgroup.
  • Joel Goldstick at Nov 18, 2013 at 5:35 pm

    On Mon, Nov 18, 2013 at 12:15 PM, E.D.G. wrote:
    "Terry Reedy" <tjreedy@udel.edu> wrote in message
    news:mailman.2820.1384745298.18130.python-list at python.org...

    A couple of sentences of follow-up would have been sufficient.

    The experience that I have had over the years with Newsgroup posting
    is that it is generally better to try to be polite and answer as many
    questions as possible even when that results in more information being
    posted than might be necessary. Hopefully a discussion will then end
    quietly on a pleasant note.

    That approach seems to usually produce good results. Quite often
    people who are happy with the tone of the public Newsgroup discussion will
    send along some valuable information by E-mail. And that has been happening
    with this present discussion that will now continue in only the Fortran
    Newsgroup.

    --
    https://mail.python.org/mailman/listinfo/python-list

    This is just plain senseless. Is the op a Bot?


    --
    Joel Goldstick
    http://joelgoldstick.com
  • E.D.G. at Nov 19, 2013 at 11:26 am

    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
    Posted by E.D.G. on November 19, 2013


    1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN


    2. COMPUTER PROGRAMMING PROJECTS




    PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN


            This program translation project has become one of the most
    surprisingly successful programming projects I have worked on to date. A
    considerable amount of valuable information has been sent to me by E-mail in
    addition to all of the information posted to the Newsgroups.


            The original posts actually discussed calculation speed matters
    involving Perl and Python. And responses indicated that there were ways to
    develop routines that could dramatically accelerate Python calculations.
    But it did not sound like there were any for Perl.


    However, a kind soul sent me the following references:


    http://pdl.perl.org/
    http://www.youtube.com/watch?v=IE-vnnRWiOg
    http://www.youtube.com/watch?v=rf1yfZ2yUFo


            From what I can see, PDL represents a group of modules that can be
    linked with Perl to do faster calculations and to generate charts. I gather
    that it converts calculations directly to the C language so that they run
    faster. And now I am wondering how those calculations would compare with
    Python and Fortran and the other programs listed on the following Web page:


    http://julialang.org/


            As soon as possible I am planning to give the PDL modules a try
    myself and see if they help with my present Perl calculation speed
    limitations.


            Does anyone have any comments they can add regarding PDL (for posting
    in the Perl Newsgroup)?


            Would those PDL modules be available on Internet Servers that let
    users develop and run Perl CGI programs? Or would they need to be specially
    installed?




    COMPUTER PROGRAMMING PROJECTS


            As most people visiting these Newsgroups probably know, computers run
    our world. And therefore, computer programmers at least indirectly run our
    world. As an experienced scientist who does some programming work I myself
    am fully aware of that. But relatively few other scientists are. And
    almost no government officials appear to be. And they are the ones who have
    all of the money.


            As an experienced scientist I regularly send free technical advice to
    governments and nongovernmental organizations (NGOs) around the world
    regarding humanitarian projects. Some of my past efforts have been highly
    successful. And because I am so aware of the importance of computer
    programming to the success of most efforts I can be especially effective
    when discussing proposed projects. I know enough about computer
    programming, electronics, and machine shop usage that I can provide the
    government officials with exact instructions for how they should proceed
    with developing some project.


            For example, sometimes the best way to get something done is with a
    specially designed electronic circuit. At other times it is more efficient
    to use a microprocessor to do the data processing.


            There are several highly important computer programming intensive
    projects that I have been attempting to get our governments to develop for
    some time. They are in my opinion needed by people around the world. I
    have several Web sites that were created so that information could be easily
    circulated regarding those projects. And as time permits I plan to start
    discussing them in various computer language Newsgroups.


            An effort is also in progress to get some modifications made to the
    U.S. Government Petitions Web Site so that it works a little better and is
    of more use to people.


    https://petitions.whitehouse.gov/


           It has been my personal experience that our government officials who
    decide which projects should get funding and how many computer programmers
    etc. need to be hired for this or that effort usually know so little about
    the work that computer programmers and even scientists do that they often
    don't have any idea regarding how to solve various problems and also often
    don't even know that certain problems exist.


    These are personal opinions.
  • Glen herrmannsfeldt at Nov 19, 2013 at 8:51 pm

    In comp.lang.fortran E.D.G. wrote:
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
    Posted by E.D.G. on November 19, 2013
    1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN

    (snip)

    This program translation project has become one of the most
    surprisingly successful programming projects I have worked on to date. A
    considerable amount of valuable information has been sent to me by E-mail in
    addition to all of the information posted to the Newsgroups.
    The original posts actually discussed calculation speed matters
    involving Perl and Python. And responses indicated that there were ways to
    develop routines that could dramatically accelerate Python calculations.
    But it did not sound like there were any for Perl.

    In general, language processors can be divided into two categories
    called compilers and interpreters. Compilers generate instructions for
    the target processors. Interpreters generate (usually) an intermediate
    representation which is then interpreted by a program to perform the
    desired operations. That latter tends to be much slower, but more
    portable.


    There are a few langauges that allow dynamic generation of code, which
    often makes compilation impossible, and those languages tend to be
    called 'interpreted langauges'.


    Some years ago when working with perl programs that ran too slow, we
    found a perl to C translator. Surprisingly, the result ran just as slow!
    It turns out that the perl to C translator generates a C program
    containing the intermediate code and the interpreter, and so runs just
    the same speed.


    More recently, there are JIT systems which generate the intermediate
    code, but then at the appropriate time (Just In Time) compile that to
    machine code and execute it. This is common for Java, and more recently
    for languages like Matlab.


    -- glen
  • Yaşar Arabacı at Nov 19, 2013 at 9:31 pm

    2013/11/19 glen herrmannsfeldt <gah@ugcs.caltech.edu>:
    More recently, there are JIT systems which generate the intermediate
    code, but then at the appropriate time (Just In Time) compile that to
    machine code and execute it. This is common for Java, and more recently
    for languages like Matlab.

    Is there a particular reason why you didn't mention PyPy?
  • Rainer Weikusat at Nov 19, 2013 at 9:35 pm

    glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
    In comp.lang.fortran E.D.G. wrote:
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
    Posted by E.D.G. on November 19, 2013
    1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN (snip)
    This program translation project has become one of the most
    surprisingly successful programming projects I have worked on to date. A
    considerable amount of valuable information has been sent to me by E-mail in
    addition to all of the information posted to the Newsgroups.
    The original posts actually discussed calculation speed matters
    involving Perl and Python. And responses indicated that there were ways to
    develop routines that could dramatically accelerate Python calculations.
    But it did not sound like there were any for Perl.
    In general, language processors can be divided into two categories
    called compilers and interpreters. Compilers generate instructions for
    the target processors. Interpreters generate (usually) an intermediate
    representation which is then interpreted by a program to perform the
    desired operations. That latter tends to be much slower, but more
    portable.

    There are a few langauges that allow dynamic generation of code, which
    often makes compilation impossible, and those languages tend to be
    called 'interpreted langauges'.

    These two paragraphs use the same terms in conflicting ways and the
    assertions in the second paragraph are wrong: Lisp is presumably the
    oldest language which allows 'dynamic code creation' and implementations
    exist which not only have a compiler but actually don't have an
    interpreter, cf


    http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation


    The main difference between a compiler and an interpreter is that the
    compiler performs lexical and semantical analysis of 'the source code'
    once and then transforms it into some kind of different 'directly
    executable representation' while an interpreter would analyze some part
    of the source code, execute it, analyze the next, execute that, and so
    forth, possibly performing lexical and semantical analysis steps many
    times for the same bit of 'source code'.


    Some compilers produce 'machine code' which can be executed directly by
    'a CPU', others generate 'machine code' for some kind of virtual machine
    which is itself implemented as a program. The distinction isn't really
    clear-cut because some CPUs are designed to run 'machine code'
    originally targetted at a virtual machine, eg, what used to be ARM
    Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
    machines are supposed to execute 'machine code' which used to run
    'directly on a CPU' in former times, eg, used for backwards
    compatibility on Bull Novascale computers.


    Prior to execution, Perl source code is compiled to 'machine code' for a
    (stack-based) virtual machine. Both the compiler and the VM are provided
    by the perl program. There were some attempts to create a standalone
    Perl compiler in the past but these never gained much traction.
  • Glen herrmannsfeldt at Nov 19, 2013 at 10:43 pm

    In comp.lang.fortran Rainer Weikusat wrote:
    glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
    In comp.lang.fortran E.D.G. wrote:
    "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
    news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
    Posted by E.D.G. on November 19, 2013
    1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN

      (snip)

    This program translation project has become one of the most
    surprisingly successful programming projects I have worked on to date. A
    considerable amount of valuable information has been sent to me by E-mail in
    addition to all of the information posted to the Newsgroups.

    (snip, I wrote)

    In general, language processors can be divided into two categories
    called compilers and interpreters. Compilers generate instructions for
    the target processors. Interpreters generate (usually) an intermediate
    representation which is then interpreted by a program to perform the
    desired operations. That latter tends to be much slower, but more
    portable.
    There are a few langauges that allow dynamic generation of code, which
    often makes compilation impossible, and those languages tend to be
    called 'interpreted langauges'.
    These two paragraphs use the same terms in conflicting ways and the
    assertions in the second paragraph are wrong: Lisp is presumably the
    oldest language which allows 'dynamic code creation' and implementations
    exist which not only have a compiler but actually don't have an
    interpreter, cf
    http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation
    The main difference between a compiler and an interpreter is that the
    compiler performs lexical and semantical analysis of 'the source code'
    once and then transforms it into some kind of different 'directly
    executable representation' while an interpreter would analyze some part
    of the source code, execute it, analyze the next, execute that, and so
    forth, possibly performing lexical and semantical analysis steps many
    times for the same bit of 'source code'.

    OK, but many intepreters at least do a syntax check on the whole file,
    and many also convert the statements to a more convenient internal
    representation.


    For an example of something that can't be compiled, consider TeX which
    allows the category code of characters to be changed dynamically.


    I once wrote self-modifying code for Mathematica, where the running code
    (on what Mathematica calls the back end) asked the front end (which does
    editing of input data) to change the code.

    Some compilers produce 'machine code' which can be executed directly by
    'a CPU', others generate 'machine code' for some kind of virtual machine
    which is itself implemented as a program. The distinction isn't really
    clear-cut because some CPUs are designed to run 'machine code'
    originally targetted at a virtual machine, eg, what used to be ARM
    Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
    machines are supposed to execute 'machine code' which used to run
    'directly on a CPU' in former times, eg, used for backwards
    compatibility on Bull Novascale computers.

    Yes. There are also systems that do simple processing on each statement,
    with no interstatement memory. Converting numerical constants to
    internal form, encoding keywords to a single byte, and such.


    It is interesting to see the program listing look different than the way
    it was entered, such as constants coming out as 1e6 when you entered
    it as 1000000. The HP2000 BASIC system is the one I still remember.


    The popular microcomputer BASIC systems, mostly from Microsoft, allowed
    things like:


    IF I=1 THEN FOR J=1 TO 10
    PRINT J
    IF I=1 THEN NEXT J


    If you left out the IF on the last line, it would fail when it reached
    the NEXT J statement if the FOR hadn't been executed. Compare to C:


    if(i==1) for(j=1;j<;j++) {
        printf("%d\n",j);
    }


    A compiler would match up the FOR and NEXT at compile time. Many
    interpreters do it at run time, depending on the current state.


    I also used to use a BASIC system that allowed you to stop a program
    (or the program stopped itself), change statements (fix bugs) and
    continue on from where it stopped. Not all can do that, but pretty
    much compilers never do.

    Prior to execution, Perl source code is compiled to 'machine code' for a
    (stack-based) virtual machine. Both the compiler and the VM are provided
    by the perl program. There were some attempts to create a standalone
    Perl compiler in the past but these never gained much traction.

    And, importantly, the code runs fairly slow. Some years ago, I was
    working with simple PERL programs that could process data at 1 megabyte
    per minute. Rewriting in C, I got one megabyte per second. It is not too
    unusual to run 10 times slower, but 60 was rediculous.


    -- glen
  • Chris Angelico at Nov 19, 2013 at 11:01 pm

    On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt wrote:
    I also used to use a BASIC system that allowed you to stop a program
    (or the program stopped itself), change statements (fix bugs) and
    continue on from where it stopped. Not all can do that, but pretty
    much compilers never do.

    Ditto, both in GW-BASIC and Q-BASIC, but in each case there were some
    fairly strict rules about what could be edited. Changing anything to
    do with control flow quickly got you a "Can't continue" error. And of
    course, assembly language with DEBUG.EXE lets you do basically
    anything... rewrite memory (code or data, there's no difference),
    change the instruction pointer (so execution resumes somewhere else),
    change other registers, etc, etc.


    Most languages don't give you quite that much flexibility, because
    it's really REALLY easy to mess things up and confuse yourself
    completely. Python kinda will, though; all you have to do is fiddle
    with sys.modules so it won't be cached, or rename the file to
    something unique before reimporting it. You can then patch in
    functions from the new module and start using them. Pike makes this
    sort of thing much more convenient; it's not hard to write code that
    smoothly slides to a new version of itself, without losing any sort of
    state. But the granularity never gets down below the function, meaning
    the Python and Pike compilers/interpreters are free to fiddle around
    inside a function (note, for instance, how Python locals basically
    just become indices into an array; it'd be a bit awkward to tweak a
    running Python function and add a 'global' declaration).


    ChrisA
    (See? I'm posting on topic!)
  • Gamo at Nov 20, 2013 at 8:48 pm
    El 19/11/13 23:43, glen herrmannsfeldt escribi?:
    And, importantly, the code runs fairly slow. Some years ago, I was
    working with simple PERL programs that could process data at 1 megabyte
    per minute. Rewriting in C, I got one megabyte per second. It is not too
    unusual to run 10 times slower, but 60 was rediculous.

    -- glen

    Can you provide more information on the topic? Perl version, method to
    read/write, etc.


    Thanks
  • Terence at Nov 16, 2013 at 9:31 am
    I downloaded the packed file mentioned, extracted the files and had a look
    at the Fortran sources given:
    ETGTAB.FOR and ETGTAB.F


    The ETGTAB.FOR file had double spacing, which Iremoved automatically, then
    compared the two sources automatically (passing and copying equals and
    offering choice between lexically different lines).


    The two files were now very nearly identical, but the .FOR file had some
    CALLs to GEOEXT(IUIT6,DEXTIM) which were commented out in the other; also
    calls to LAHEY timing functions not used in the .F version (and a minor
    change in two format statements which effectively just changed the shift in
    the output report).


    I don't see why not either source (given access to the external GEOEXT, etc,
    fuctions) shouldn't be left for compilation (and later running) by any F77
    or later compiler. The code is still valid.
  • William Ray Wing at Nov 16, 2013 at 2:00 pm

    On Nov 16, 2013, at 4:31 AM, Terence wrote:


    I downloaded the packed file mentioned, extracted the files and had a look
    at the Fortran sources given:
    ETGTAB.FOR and ETGTAB.F

    The ETGTAB.FOR file had double spacing, which Iremoved automatically, then
    compared the two sources automatically (passing and copying equals and
    offering choice between lexically different lines).

    The two files were now very nearly identical, but the .FOR file had some
    CALLs to GEOEXT(IUIT6,DEXTIM) which were commented out in the other; also
    calls to LAHEY timing functions not used in the .F version (and a minor
    change in two format statements which effectively just changed the shift in
    the output report).

    I don't see why not either source (given access to the external GEOEXT, etc,
    fuctions) shouldn't be left for compilation (and later running) by any F77
    or later compiler. The code is still valid.

    Then, use F2PY to put a python wrapper around the code, and it could easily be incorporated into the python workflow that the OP was originally asking for.


    -Bill

Related Discussions

People

Translate

site design / logo © 2022 Grokbase