Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #59435 > unrolled thread

Program Translation - Nov. 14, 2013

Back to article view | Back to comp.lang.python

Contents

  Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-14 08:18 -0600
    Re: Program Translation - Nov. 14, 2013 mecej4 <mecej4_nospam@operamail.com> - 2013-11-14 11:07 -0600
      Re: Program Translation - Nov. 14, 2013 Gordon Sande <Gordon.Sande@gmail.com> - 2013-11-14 13:36 -0400
        Re: Program Translation - Nov. 14, 2013 Clive Page <usenet@page2.eu> - 2013-11-15 11:46 +0000
      Re: Program Translation - Nov. 14, 2013 Jürgen Exner <jurgenex@hotmail.com> - 2013-11-17 09:02 -0800
    Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-15 07:51 -0600
      Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 04:25 -0600
        Re: Program Translation - Nov. 14, 2013 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-17 12:45 +0000
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 08:37 -0600
            Re: Program Translation - Nov. 14, 2013 Henry Law <news@lawshouse.org> - 2013-11-17 14:42 +0000
              Re: Program Translation - Nov. 14, 2013 Roy Smith <roy@panix.com> - 2013-11-17 10:20 -0500
                Re: Program Translation - Nov. 14, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-18 02:28 +1100
                Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 10:25 -0600
                  Re: Program Translation - Nov. 14, 2013 Tim Prince <tprince@computer.org> - 2013-11-17 08:30 -0800
                    Re: Program Translation - Nov. 14, 2013 Roy Smith <roy@panix.com> - 2013-11-17 11:43 -0500
                      Re: Program Translation - Nov. 14, 2013 nospam@see.signature (Richard Maine) - 2013-11-17 09:05 -0800
                        Re: Program Translation - Nov. 14, 2013 Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-17 12:29 -0500
                          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-18 11:30 -0600
                Re: Program Translation - Nov. 14, 2013 Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-17 18:59 +0000
            Re: Program Translation - Nov. 14, 2013 "James Van Buskirk" <not_valid@comcast.net> - 2013-11-17 09:05 -0700
          Re: Program Translation - Nov. 14, 2013 Charlton Wilbur <cwilbur@chromatico.net> - 2013-11-17 23:22 -0500
        Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 10:17 -0600
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 12:07 -0600
        Re: Program Translation - Nov. 14, 2013 Terry Reedy <tjreedy@udel.edu> - 2013-11-17 22:28 -0500
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-18 11:15 -0600
            Re: Program Translation - Nov. 14, 2013 Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-18 12:35 -0500
        Several Topics - Nov. 19, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-19 05:26 -0600
          Re: Several Topics - Nov. 19, 2013 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-19 20:51 +0000
            Re: Several Topics - Nov. 19, 2013 Yaşar Arabacı <yasar11732@gmail.com> - 2013-11-19 23:31 +0200
            Re: Several Topics - Nov. 19, 2013 Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-19 21:35 +0000
              Re: Several Topics - Nov. 19, 2013 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-19 22:43 +0000
                Re: Several Topics - Nov. 19, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-20 10:01 +1100
                Re: Several Topics - Nov. 19, 2013 gamo <gamo@telecable.es> - 2013-11-20 21:48 +0100
    Re: Program Translation - Nov. 14, 2013 "Terence" <tbwright@bigpond.net.au> - 2013-11-16 20:31 +1100
      Re: Program Translation - Nov. 14, 2013 William Ray Wing <wrw@mac.com> - 2013-11-16 09:00 -0500

Page 1 of 2  [1] 2  Next page →

#59435 — Program Translation - Nov. 14, 2013

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.

[toc] | [next] | [standalone]

#59455

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

[toc] | [prev] | [next] | [standalone]

#59458

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.

[toc] | [prev] | [next] | [standalone]

#59512

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

[toc] | [prev] | [next] | [standalone]

#59761

mecej4 <mecej4_nospam@operamail.com> 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

[toc] | [prev] | [next] | [standalone]

#59519

"E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.

[toc] | [prev] | [next] | [standalone]

#59711

"E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
news:jcKdnQiu1ZxguxvPnZ2dnUVZ_qmdnZ2d@earthlink.com...
> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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."

[toc] | [prev] | [next] | [standalone]

#59717

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

> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
> news:jcKdnQiu1ZxguxvPnZ2dnUVZ_qmdnZ2d@earthlink.com...
>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.

[toc] | [prev] | [next] | [standalone]

#59735

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.444ab0f1470c9d9a7a89.20131117124526GMT.87li0nqjrt.fsf@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.

[toc] | [prev] | [next] | [standalone]

#59736

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

[toc] | [prev] | [next] | [standalone]

#59740

In article <xMydnRjrQ45fSBXPnZ2dnUVZ8mGdnZ2d@giganews.com>,
 Henry Law <news@lawshouse.org> 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.

[toc] | [prev] | [next] | [standalone]

#59742

On Mon, Nov 18, 2013 at 2:20 AM, Roy Smith <roy@panix.com> 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

[toc] | [prev] | [next] | [standalone]

#59757

"Roy Smith" <roy@panix.com> wrote in message 
news:roy-D4B9A4.10202517112013@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.

[toc] | [prev] | [next] | [standalone]

#59758

On 11/17/2013 8:25 AM, E.D.G. wrote:
> "Roy Smith" <roy@panix.com> wrote in message
> news:roy-D4B9A4.10202517112013@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

[toc] | [prev] | [next] | [standalone]

#59759

In article <bes9a5Ffm6dU1@mid.individual.net>,
 Tim Prince <tprince@computer.org> 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?

[toc] | [prev] | [next] | [standalone]

#59762

Roy Smith <roy@panix.com> wrote:

> In article <bes9a5Ffm6dU1@mid.individual.net>,
>  Tim Prince <tprince@computer.org> 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

[toc] | [prev] | [next] | [standalone]

#59772

On Sun, Nov 17, 2013 at 12:05 PM, Richard Maine <nospam@see.signature> wrote:
> Roy Smith <roy@panix.com> wrote:
>
>> In article <bes9a5Ffm6dU1@mid.individual.net>,
>>  Tim Prince <tprince@computer.org> 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

[toc] | [prev] | [next] | [standalone]

#59894

"Joel Goldstick" <joel.goldstick@gmail.com> wrote in message 
news:mailman.2792.1384709379.18130.python-list@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.

[toc] | [prev] | [next] | [standalone]

#59786

Roy Smith <roy@panix.com> writes:
>  Henry Law <news@lawshouse.org> 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'?

[toc] | [prev] | [next] | [standalone]

#59752

"E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
news:F7mdndYtY6YrSRXPnZ2dnUVZ_oWdnZ2d@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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web