[32814] in Perl-Users-Digest
Perl-Users Digest, Issue: 4079 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Nov 17 14:09:37 2013
Date: Sun, 17 Nov 2013 11:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 17 Nov 2013 Volume: 11 Number: 4079
Today's topics:
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Program Translation - Nov. 14, 2013 <ben.usenet@bsb.me.uk>
Re: Program Translation - Nov. 14, 2013 <news@lawshouse.org>
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Program Translation - Nov. 14, 2013 <news@lawshouse.org>
Re: Program Translation - Nov. 14, 2013 <roy@panix.com>
Re: Program Translation - Nov. 14, 2013 <not_valid@comcast.net>
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Program Translation - Nov. 14, 2013 <tprince@computer.org>
Re: Program Translation - Nov. 14, 2013 <roy@panix.com>
Re: Program Translation - Nov. 14, 2013 <jurgenex@hotmail.com>
Re: Program Translation - Nov. 14, 2013 (Richard Maine)
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Program Translation - Nov. 14, 2013 <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 17 Nov 2013 04:25:37 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <UdKdnSzeg-k9BBXPnZ2dnUVZ_vadnZ2d@earthlink.com>
"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."
------------------------------
Date: Sun, 17 Nov 2013 12:45:26 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <0.444ab0f1470c9d9a7a89.20131117124526GMT.87li0nqjrt.fsf@bsb.me.uk>
"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.
------------------------------
Date: Sun, 17 Nov 2013 14:31:41 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <8aCdneu0457TThXPnZ2dnUVZ8mednZ2d@giganews.com>
On 17/11/13 10:25, E.D.G. wrote:
> ... So, what we are attempting to do is get it
> translated into some modern language
FORTRAN is modern. Lots of people use it. There are ports for lots of
different platforms. Think very carefully before you do that. (Which
is to say, don't!)
that researchers around the world
> can have their own programmers easily modify for their specific uses.
In True BASIC? You're joking, aren't you? Non-free, proprietary (so
that support could disappear), locked to Windows ... even if you do
ignore the advice above (and that from other posters), True BASIC is a
terrible choice for doing it because none of these researchers will have
the skills or the software with which to do it.
They won't know how good your code is (if it is) unless they try it, and
they won't try it unless they are convinced of how good it is (because
they need to spend money on a language, and develop skills in it).
You're deluding yourself, I fear.
> 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.
Appreciate your wish to stay with someone you've worked with, and who is
free resource at that, but you've lost perspective. True BASIC is not
the answer, so this chap isn't the right person to help.
> I myself will create a Perl language program
If you don't mind my saying so, learn to program in Perl first.
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.
Why would you hobble a widely-available language like Perl or Python
with a back-end written in some niche language? Really; I mean it:
don't do that!
--
Henry Law Manchester, England
------------------------------
Date: Sun, 17 Nov 2013 08:37:44 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <F7mdndYtY6YrSRXPnZ2dnUVZ_oWdnZ2d@earthlink.com>
"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.
------------------------------
Date: Sun, 17 Nov 2013 14:42:10 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <xMydnRjrQ45fSBXPnZ2dnUVZ8mGdnZ2d@giganews.com>
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
------------------------------
Date: Sun, 17 Nov 2013 10:20:25 -0500
From: Roy Smith <roy@panix.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <roy-D4B9A4.10202517112013@news.panix.com>
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.
------------------------------
Date: Sun, 17 Nov 2013 09:05:08 -0700
From: "James Van Buskirk" <not_valid@comcast.net>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <l6apfo$n02$1@dont-email.me>
"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
------------------------------
Date: Sun, 17 Nov 2013 10:17:59 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <486dne6fDNapcRXPnZ2dnUVZ_s-dnZ2d@earthlink.com>
>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.
------------------------------
Date: Sun, 17 Nov 2013 10:25:17 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <Xv-dnYmZ_vB0cBXPnZ2dnUVZ_jKdnZ2d@earthlink.com>
"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.
------------------------------
Date: Sun, 17 Nov 2013 08:30:58 -0800
From: Tim Prince <tprince@computer.org>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <bes9a5Ffm6dU1@mid.individual.net>
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
------------------------------
Date: Sun, 17 Nov 2013 11:43:53 -0500
From: Roy Smith <roy@panix.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <roy-4F76EF.11435317112013@news.panix.com>
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?
------------------------------
Date: Sun, 17 Nov 2013 09:02:09 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <jeth89973biochb1885gp7r0k2p7mpedj5@4ax.com>
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
------------------------------
Date: Sun, 17 Nov 2013 09:05:40 -0800
From: nospam@see.signature (Richard Maine)
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <1lch2h3.6ef81xmjiepuN%nospam@see.signature>
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
------------------------------
Date: Sun, 17 Nov 2013 12:07:11 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <TbKdnXsxv8tWmBTPnZ2dnUVZ_smdnZ2d@earthlink.com>
>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.
------------------------------
Date: Sun, 17 Nov 2013 18:59:16 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <87bo1ij1mj.fsf@sable.mobileactivedefense.com>
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'?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4079
***************************************
