[32815] in Perl-Users-Digest
Perl-Users Digest, Issue: 4080 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 19 18:09:42 2013
Date: Tue, 19 Nov 2013 15: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 Tue, 19 Nov 2013 Volume: 11 Number: 4080
Today's topics:
Re: 'depth n' combinations of a sequence of numbers <gamo@telecable.es>
Re: 'depth n' combinations of a sequence of numbers <hslee911@yahoo.com>
Re: 'depth n' combinations of a sequence of numbers <rweikusat@mobileactivedefense.com>
Re: 'depth n' combinations of a sequence of numbers <gamo@telecable.es>
Re: 'depth n' combinations of a sequence of numbers <gamo@telecable.es>
Re: 'depth n' combinations of a sequence of numbers <gamo@telecable.es>
Re: Program Translation - Nov. 14, 2013 <cwilbur@chromatico.net>
Re: Program Translation - Nov. 14, 2013 <gamo@telecable.es>
Re: Program Translation - Nov. 14, 2013 <cwilbur@chromatico.net>
Re: Program Translation - Nov. 14, 2013 (Tim McDaniel)
Re: Program Translation - Nov. 14, 2013 <cwilbur@chromatico.net>
Re: Several Perl Questions - Nov. 5, 2013 <cwilbur@chromatico.net>
Re: Several Perl Questions - Nov. 5, 2013 <rvtol+usenet@xs4all.nl>
Several Topics - Nov. 19, 2013 <edgrsprj@ix.netcom.com>
Re: Several Topics - Nov. 19, 2013 <gah@ugcs.caltech.edu>
Re: Several Topics - Nov. 19, 2013 <rweikusat@mobileactivedefense.com>
Re: Several Topics - Nov. 19, 2013 <gah@ugcs.caltech.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Nov 2013 08:08:51 +0100
From: gamo <gamo@telecable.es>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <l6ceeg$4s1$1@speranza.aioe.org>
El 15/11/13 02:06, James escribió:
> Using "glob" as suggested by DeRykus, for list [$p..$q] and depth $d,
>
> use Data::Dump qw(dump);
> ($p, $q, $d) = @ARGV;
> $x = join ",", $p..$q;
>
> dump run($x,$d);
>
> sub run {
> my ($T, $d) = @_;
> if ($d == 1) {
> glob "{@{[$T]}}";
> } else {
> $T = join ",", run($T, --$d);
> glob "{@{[$x]}}_{@{[$T]}}";
> }
> }
>
> James
>
I'm afraid this has to be parsed and that delays the final result.
Here is a comparison of methods:
Brute force method takes 0.000116 s.
Intelligent method takes 0.001029 s.
Reiner #a gen() takes 0.000337 s. (requires finish)
Reiner #b rings() takes 0.000573 s. (requires finish)
James glob method takes 0.00066 s. and bad return, to be parsed
Then, and in counter-intuitive results, the best method to do
variations_with_repetition of order 2 in a short list is:
@data = 0..31;
for $i (@data){
for $j (@data){
push @results, ($i,$j);
}
}
which I call it the "brute force" approach. It's simpler, more
agile, in a task that it's not very sensitive a priori by the
upper bound of only 1 milisecond.
Best regards
------------------------------
Date: Mon, 18 Nov 2013 12:12:46 -0800 (PST)
From: James <hslee911@yahoo.com>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <582fca08-4a43-49ec-ad9b-39cb75c4a16f@googlegroups.com>
On Sunday, November 17, 2013 11:08:51 PM UTC-8, gamo wrote:
> El 15/11/13 02:06, James escribi=F3:
>=20
> > Using "glob" as suggested by DeRykus, for list [$p..$q] and depth $d,
>=20
> >
>=20
> > use Data::Dump qw(dump);
>=20
> > ($p, $q, $d) =3D @ARGV;
>=20
> > $x =3D join ",", $p..$q;
>=20
> >
>=20
> > dump run($x,$d);
>=20
> >
>=20
> > sub run {
>=20
> > my ($T, $d) =3D @_;
>=20
> > if ($d =3D=3D 1) {
>=20
> > glob "{@{[$T]}}";
>=20
> > } else {
>=20
> > $T =3D join ",", run($T, --$d);
>=20
> > glob "{@{[$x]}}_{@{[$T]}}";
>=20
> > }
>=20
> > }
>=20
> >
>=20
> > James
>=20
> >
>=20
>=20
>=20
> I'm afraid this has to be parsed and that delays the final result.
>=20
>=20
>=20
> Here is a comparison of methods:
>=20
>=20
>=20
> Brute force method takes 0.000116 s.
>=20
> Intelligent method takes 0.001029 s.
>=20
> Reiner #a gen() takes 0.000337 s. (requires finish)
>=20
> Reiner #b rings() takes 0.000573 s. (requires finish)
>=20
> James glob method takes 0.00066 s. and bad return, to be parsed
>=20
>=20
>=20
> Then, and in counter-intuitive results, the best method to do
>=20
> variations_with_repetition of order 2 in a short list is:
>=20
>=20
>=20
> @data =3D 0..31;
>=20
>=20
>=20
> for $i (@data){
>=20
> for $j (@data){
>=20
> push @results, ($i,$j);
>=20
> }
>=20
> }=09
>=20
>=20
>=20
>=20
>=20
> which I call it the "brute force" approach. It's simpler, more
>=20
> agile, in a task that it's not very sensitive a priori by the
>=20
> upper bound of only 1 milisecond.
>=20
>=20
>=20
> Best regards
Have you tried benchmark for depth 3 or more?
Regards,
James
------------------------------
Date: Mon, 18 Nov 2013 20:30:32 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <874n79h2qf.fsf@sable.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 15/11/13 02:06, James escribió:
[...]
> I'm afraid this has to be parsed and that delays the final result.
>
> Here is a comparison of methods:
>
> Brute force method takes 0.000116 s.
> Intelligent method takes 0.001029 s.
> Reiner #a gen() takes 0.000337 s. (requires finish)
> Reiner #b rings() takes 0.000573 s. (requires finish)
> James glob method takes 0.00066 s. and bad return, to be parsed
>
> Then, and in counter-intuitive results, the best method to do
> variations_with_repetition of order 2 in a short list is:
>
> @data = 0..31;
>
> for $i (@data){
> for $j (@data){
> push @results, ($i,$j);
> }
> }
>
>
> which I call it the "brute force" approach.
This is not a generator, it is certainly not a generator constructed by
a recursive function and it doesn't even create pairs, just a flat list
of numbers. Considering this, something which is going to be a hell lot
faster and also doesn't work would be
perl -e ';'
------------------------------
Date: Tue, 19 Nov 2013 02:50:17 +0100
From: gamo <gamo@telecable.es>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <l6eg59$i5l$1@speranza.aioe.org>
El 18/11/13 21:12, James escribió:
>
> Have you tried benchmark for depth 3 or more?
>
No, but I tried now. Let's say the order of the variations is 4, higher
enough to not to try to loop over @data. Then, the number of variations
with repetition is 32**4. I stored in an array all the variations from
the literature method (module in C) and the Rainer's method. It takes
a decent size to not to try with 5 at home. Timing is 1.157 sec. for the
classical method and 0.819 for the Rainer's method, which suggest
that is a good method. But at end of the Rainer's array (stopped at
++$count == 32**4) I saw an anomaly: the quad 31 31 31 31 is repeated
in 32**4-1 and 32**4. The output in the classic method is correct:
31 31 31 30 and 31 31 31 31. So, I don't know what to say. I need to
check later.
Best regards
------------------------------
Date: Tue, 19 Nov 2013 03:05:41 +0100
From: gamo <gamo@telecable.es>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <l6eh24$kcd$1@speranza.aioe.org>
El 19/11/13 02:50, gamo escribió:
> El 18/11/13 21:12, James escribió:
>>
>> Have you tried benchmark for depth 3 or more?
>>
>
> No, but I tried now. Let's say the order of the variations is 4, higher
> enough to not to try to loop over @data. Then, the number of variations
> with repetition is 32**4. I stored in an array all the variations from
> the literature method (module in C) and the Rainer's method. It takes
> a decent size to not to try with 5 at home. Timing is 1.157 sec. for the
> classical method and 0.819 for the Rainer's method, which suggest
> that is a good method. But at end of the Rainer's array (stopped at
> ++$count == 32**4) I saw an anomaly: the quad 31 31 31 31 is repeated
> in 32**4-1 and 32**4. The output in the classic method is correct:
> 31 31 31 30 and 31 31 31 31. So, I don't know what to say. I need to
> check later.
>
> Best regards
>
>
Oops! It's my fault. I pushed two times the @tuple.
Sorry.
So, the Rainer's method appears to be very good.
Good night
------------------------------
Date: Tue, 19 Nov 2013 23:23:31 +0100
From: gamo <gamo@telecable.es>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <l6godg$437$1@speranza.aioe.org>
El 18/11/13 21:30, Rainer Weikusat escribió:
> gamo <gamo@telecable.es> writes:
>> which I call it the "brute force" approach.
>
> This is not a generator, it is certainly not a generator constructed by
> a recursive function and it doesn't even create pairs, just a flat list
> of numbers. Considering this, something which is going to be a hell lot
> faster and also doesn't work would be
>
> perl -e ';'
>
>
Well in fact, running perl to do nothing could take 2 miliseconds, where
generating the list of variations takes 1.
Jokes and "negation mode" apart, if you have the list of pairs of
variations you could cycle over it as free as you want, one by one,
by steps, take random pairs, etc. You know perfectly this, and I
know that you know.
Best regards
------------------------------
Date: Sun, 17 Nov 2013 23:22:30 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <87pppy1gqh.fsf@new.chromatico.net>
>>>>> "BB" == Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
BB> There is a slight air in unreality to all this,
This is a far more polite way of putting it than I would. It's an
earthquake predictor based on pseudoscience and technobabble.
BB> Finally, why are you timing Perl arithmetic? A translation into
BB> Perl does not seem to be an option.
EDG has been trying ineffectually to get this suite of programs to work,
integrating them with gnuplot and a Perl web application, for as long as
I can remember. I suspect years ago someone told him that Perl was the
One True Language for web applications and the evidence of the
intervening decade has not been enough to convince him otherwise.
Followups set to comp.lang.perl.misc; c.l.python and c.l.fortran have
enough crazy overlap from c.l.p.m without adding me to the mix.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 18 Nov 2013 15:43:19 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <l6d92j$8ge$1@speranza.aioe.org>
El 18/11/13 05:22, Charlton Wilbur escribió:
>>>>>> "BB" == Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> BB> There is a slight air in unreality to all this,
>
> This is a far more polite way of putting it than I would. It's an
> earthquake predictor based on pseudoscience and technobabble.
>
Maybe, but who knows? AFAIK could be small earthquakes caused
by man made interventions. There was a recent scandal in Spain
about that.
Anyway, giving to someone an opinion is cheap. Recently I look
at open mpi project and see F77 and F90 examples. So, Fortran
it's not dead and he could stay with it and do new things in
that or another language, i.e. using files between them.
------------------------------
Date: Mon, 18 Nov 2013 15:04:40 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <87d2lx1non.fsf@new.chromatico.net>
>>>>> "g" == gamo <gamo@telecable.es> writes:
g> El 18/11/13 05:22, Charlton Wilbur escribió:
>> This is a far more polite way of putting it than I would. It's
>> an earthquake predictor based on pseudoscience and technobabble.
g> Maybe, but who knows?
This is why we have the scientific method. If EDG's model is useful, it
will have predictive power, and he should be able to predict an
earthquake with it. So he says something like "according to my model,
there will be an earthquake of this approximate magnitude at this
location in the month of February 2014." Then we wait and see.
Without that falsifiable hypothesis, then all he has is pseudoscience
and technobabble. He's been at this project for several years now and
to my knowledge has not made one verifiable prediction. This puts him
in the class of charlatan and mountebank; at least he is not trying to
convince us of the existence of ectoplasm or give us messages from our
dead relatives.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 19 Nov 2013 05:13:50 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <l6es2e$mqf$1@reader1.panix.com>
In article <87d2lx1non.fsf@new.chromatico.net>,
Charlton Wilbur <cwilbur@chromatico.net> wrote:
>This is why we have the scientific method. If EDG's model is useful,
>it will have predictive power, and he should be able to predict an
>earthquake with it. So he says something like "according to my
>model, there will be an earthquake of this approximate magnitude at
>this location in the month of February 2014." Then we wait and see.
Also, the field of precise local earthquake prediction has had a lot
of attempts and falsified claims. ("Precise" to exclude long-term
probabilities, which are along the lines of "the 2008 Uniform
California Earthquake Rupture Forecast (UCERF) has estimated that the
probability of an M >= 6.7 earthquake within the next 30 years on the
northern and southern segments of the San Andreas fault is somewhere
between 21% and 59%.")
So I think it's more plausible to have a priori suspicion of claims
here.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 19 Nov 2013 16:46:56 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <8761ro12un.fsf@new.chromatico.net>
>>>>> "TMcD" == Tim McDaniel <tmcd@panix.com> writes:
TMcD> So I think it's more plausible to have a priori suspicion of
TMcD> claims here.
Oh, I think it's entirely likely that the whole earthquake prediction
project is Internet-amplified crackpottery of the least harmful and most
entertaining sort. But the response to "you never know" is
"extraordinary claims require extraordinary evidence," and the number of
people who simply don't understand the scientific method -- and thus who
say "you never know" because they will never, in fact, know -- is
staggering.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 17 Nov 2013 23:10:20 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <87vbzq1har.fsf@new.chromatico.net>
>>>>> "BB" == Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
BB> I get the point. However the question is surely whether there
BB> might be someone who understands this code in the future? It
BB> might then be possible understand the output. I don't think
BB> this is an unreasonable hope.
I think the question is whether there is any overlap among the set of
people who understand this code, the set of people who are willing to
work with EDG, and the set of people who are willing to do the work for
the rates EDG is willing to pay.
My sense is that the intersection of those three sets is the null set.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 18 Nov 2013 20:04:44 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
To: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <528A64CC.1070004@xs4all.nl>
On 2013-11-05 07:16, E.D.G. wrote:
> Question 1
>
> Are there modules for any Perl versions that enable Perl to do
> faster calculations?
>
> At the present time the standard math and "use Math::Trig"
> options are being used. And I am running into problems with how long it
> can take Perl to do large numbers of relatively simple calculations.
>
> If there isn't a faster way to do things then the plan is to have
> my Perl programs call external programs such as a Basic or Fortran
> programs, have them do the calculations and then store the results in a
> file that the Perl program will read.
Check out PDL.
http://www.youtube.com/watch?v=rf1yfZ2yUFo
http://www.youtube.com/watch?v=IE-vnnRWiOg
--
Ruud
------------------------------
Date: Tue, 19 Nov 2013 05:26:16 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Several Topics - Nov. 19, 2013
Message-Id: <N6qdnQB9idNM1xbPnZ2dnUVZ_sadnZ2d@earthlink.com>
>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.
------------------------------
Date: Tue, 19 Nov 2013 20:51:15 +0000 (UTC)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6gj03$khv$1@speranza.aioe.org>
In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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
------------------------------
Date: Tue, 19 Nov 2013 21:35:19 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <87fvqs6pns.fsf@sable.mobileactivedefense.com>
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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.
------------------------------
Date: Tue, 19 Nov 2013 22:43:35 +0000 (UTC)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6gpin$6sp$1@speranza.aioe.org>
In comp.lang.fortran Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
>>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@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
------------------------------
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 4080
***************************************
