Program Translation - Nov. 14, 2013

[E.D.G.]

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.

[mecej4]

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]

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]

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

[E.D.G.]

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

[Terence]

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]

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

[E.D.G.]

"E.D.G." <edgr...@ix.netcom.com> wrote in message

news:jcKdnQiu1ZxguxvP...@earthlink.com...

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

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

> "E.D.G." <edgr...@ix.netcom.com> wrote in message
> news:jcKdnQiu1ZxguxvP...@earthlink.com...
>> "E.D.G." <edgr...@ix.netcom.com> wrote in message
>> news:ro-dnch2dPtbRhnP...@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.]

"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.444ab0f1470c9d9a7a89.2013...@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]

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]

In article <xMydnRjrQ45fSBXP...@giganews.com>,

Henry Law <ne...@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.

[Chris Angelico]

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

[James Van Buskirk]

"E.D.G." <edgr...@ix.netcom.com> wrote in message

news:F7mdndYtY6YrSRXP...@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

[E.D.G.]

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

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

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]

In article <bes9a5...@mid.individual.net>,

Tim Prince <tpr...@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?

[J�rgen Exner]

mecej4 <mecej4...@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

[Richard Maine]

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]

> --
> 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.]

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

[Rainer Weikusat]

Roy Smith <r...@panix.com> writes:
> Henry Law <ne...@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'?

[Terry Reedy]

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

[Charlton Wilbur]

>>>>> "BB" == Ben Bacarisse <ben.u...@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
cwi...@chromatico.net

[E.D.G.]

"Terry Reedy" <tjr...@udel.edu> wrote in message
news:mailman.2820.1384745...@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.

[E.D.G.]

"Joel Goldstick" <joel.go...@gmail.com> wrote in message
news:mailman.2792.1384709...@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.

[Joel Goldstick]

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

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

[E.D.G.]

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

In comp.lang.fortran E.D.G. <edgr...@ix.netcom.com> wrote:
>>> "E.D.G." <edgr...@ix.netcom.com> wrote in message
>>> news:ro-dnch2dPtbRhnP...@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ı]

2013/11/19 glen herrmannsfeldt <g...@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?

--
http://ysar.net/

[Rainer Weikusat]

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> In comp.lang.fortran E.D.G. <edgr...@ix.netcom.com> wrote:
>>>> "E.D.G." <edgr...@ix.netcom.com> wrote in message
>>>> news:ro-dnch2dPtbRhnP...@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]

In comp.lang.fortran Rainer Weikusat <rwei...@mobileactivedefense.com> wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>> In comp.lang.fortran E.D.G. <edgr...@ix.netcom.com> wrote:
>>>>> "E.D.G." <edgr...@ix.netcom.com> wrote in message
>>>>> news:ro-dnch2dPtbRhnP...@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<=10;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]

On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt
<g...@ugcs.caltech.edu> 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]

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