Re: Several Topics - Nov. 19, 2013
glen herrmannsfeldt g...@ugcs.caltech.edu writes: In comp.lang.fortran E.D.G. edgrs...@ix.netcom.com wrote: E.D.G. edgrs...@ix.netcom.com wrote in message news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Program Translation - Nov. 14, 2013
Roy Smith r...@panix.com writes: Henry Law n...@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'? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why do Perl programmers make more money than Python programmers
j...@toerring.de (Jens Thoms Toerring) writes: In comp.lang.python Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 05 May 2013 12:11:11 -0500, Ignoramus16992 wrote: According to CIO.com, Python programmers make only $83,000 per year, while Perl programmers make $93,000 per year. http://www.cio.com/slideshow/detail/97819?source=ifwartcio#slide10 http://www.cio.com/slideshow/detail/97819?source=ifwartcio#slide11 I would like to know, what explains the discrepancy. Perl is much harder to use, so the average Perl programmer burns out after a few years and takes up a less stressful career, like going undercover in the Russian mob or the Taliban. So only the most dedicated, brilliant and extreme programmers last long enough to become a Perl expert, and consequently can demand higher pay, while any idiot can learn to program Python, as I have. Also, Perl programmers are an unprincipled, devious bunch, always looking for an opportunity to blackmail their employers into paying them extra. Python programmers are a decent, law-abiding people with a strong moral code who would never stoop to the sort of things that Perl coders are proud of doing. Now you got me badly worried, using both Perl and Python (and other, unspeakable languages, but not VB I promise!) Will I end up as a Python hacker for the mob or worse https://en.wikipedia.org/wiki/Strange_Case_of_Dr_Jekyll_and_Mr_Hyde [SCNR] -- http://mail.python.org/mailman/listinfo/python-list
Re: f python?
Shmuel (Seymour J.) Metz spamt...@library.lspace.org.invalid writes: In 87wr5nl54w@sapphire.mobileactivedefense.com, on 04/10/2012 at 09:10 PM, Rainer Weikusat rweiku...@mssgmbh.com said: 'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the first/rest terminology can be sensibly applied to 'C strings' (which are similar to linked-lists in the sense that there's a 'special termination value' instead of an explicit length) A syringe is similar to a sturgeon in the sense that they both start with S. And the original definition of 'idiot' is 'a guy who cannot learn because he is too cocksure to already know everything'. Not that this would matter in the given context ... LISP doesn't have arrays, Lisp has arrays. and C doesn't allow you to insert into the middle of an array. Well, of course it does: You just have to move the content of all memory cells 'after' the new insert 'one up'. But unless I'm very much mistaken, the topic was first and rest (car and cdr), as the terms could be used with a C string and not whatever Shmuel happens to believe to know ... -- http://mail.python.org/mailman/listinfo/python-list
Re: f python?
Shmuel (Seymour J.) Metz spamt...@library.lspace.org.invalid writes: In 20120409111329@kylheku.com, on 04/09/2012 at 06:55 PM, Kaz Kylheku k...@kylheku.com said: Null-terminated C strings do the same thing. C arrays are not LISP strings; there is no C analog to car and cdr. 'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the first/rest terminology can be sensibly applied to 'C strings' (which are similar to linked-lists in the sense that there's a 'special termination value' instead of an explicit length) was already explained elsewhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: f python?
Shmuel (Seymour J.) Metz spamt...@library.lspace.org.invalid writes: [...] For one thing, if s is a non-empty null terminated string then, cdr(s) is also a string representing the rest of that string without the first character, Are you really too clueless to differentiate between C and LISP? In LISP, a list is a set of conses (pairs) whose car (first element of the pair) contains a value and whose cdr (second element of the pair) links to the next cons that's part of the list. The end of a list is marked by a cdr whose value is nil. A so-called 'C string' is a sequentially allocated sequence of memory locations which contain the characters making up the string and the end of it is marked by a memory location holding the value 0. This is logically very similar to the LISP list and it shouldn't be to difficult to understand that 'cdr(s) is also a string representing the rest of the string' means 'given that s points to a non-empty C string, s + 1 points to a possibly empty C string which is identical with s with the first character removed'. Null terminated strings have simplified all kids of text manipulation, lexical scanning, and data storage/communication code resulting in immeasurable savings over the years. Yeah, especially code that needs to deal with lengths and nulls. It's great for buffer overruns too. This is, I think, a case where the opinions of people who have used C strings and the opinions of people who haven't differ greatly. A nice German proverb applicable to situations like that would be 'Was der Bauer nicht kennt das frisst er nicht' ... -- http://mail.python.org/mailman/listinfo/python-list
Re: f python?
Rainer Weikusat rweiku...@mssgmbh.com writes:
Shmuel (Seymour J.) Metz spamt...@library.lspace.org.invalid writes:
[...]
For one thing, if s is a non-empty null terminated string then,
cdr(s) is also a string representing the rest of that string
without the first character,
Are you really too clueless to differentiate between C and LISP?
In LISP, a list is a set of conses (pairs) whose car (first element of
the pair) contains a value and whose cdr (second element of the pair)
links to the next cons that's part of the list. The end of a list is
marked by a cdr whose value is nil.
Addition: This can also be implemented very neatly in Perl by using
two element array references as 'cons cells', toy example
---
sub car
{
return $_[0][0];
}
sub cdr
{
return $_[0][1];
}
sub list
{
@_ [shift, list];
}
$l = list(0 .. 100);
while ($l) {
print(car($l), ' ');
$l = cdr($l);
}
print(\n);
---
and for algorithms which are well-suited for linked lists, this can
even outperform (when suitably implemented) an equivalent algorithm
using arrays.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is Programing Art or Science?
Xah Lee xah...@gmail.com writes: [...] For example, “Is mathematics science or art?”, is the same type of question that has been broached by dabblers now and then. http://en.wikipedia.org/wiki/Liberal_arts HTH. -- http://mail.python.org/mailman/listinfo/python-list
Re: lang comparison: in-place algorithm for reversing a list in Perl, Python, Lisp
Xah Lee xah...@gmail.com writes:
[...]
# perl
# in-place algorithm for reversing a list.
use strict;
use Data::Dumper;
use POSIX; # for “floor”
my @listA = qw(a b c d e f g);
my $listLength = scalar @listA;
for ( my $i = 0; $i floor($listLength/2); $i++ ) {
my $x = $listA[$i];
$listA[$i] = $listA[ $listLength - 1 - $i];
$listA[ $listLength - 1 - $i] = $x;
}
print Dumper(\@listA);
Better algorithm for that (expects an array reference as first
argument)
sub rev
{
my $a = $_[0];
my ($n0, $n1, $x);
$n0 = 0;
$n1 = $#$a;
while ($n0 $n1) {
$x = $a-[$n0];
$a-[$n0] = $a-[$n1];
$a-[$n1] = $x;
++$n0;
--$n1;
}
}
NB: The fact that a sufficiently sophisticated compiler might be able
to fix this automatically emphasizes the deficiencies of the original
attempt, it doesn't excuse them.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
Shmuel (Seymour J.) Metz spamt...@library.lspace.org.invalid writes: In 87aa41k6x5@sapphire.mobileactivedefense.com, on 02/29/2012 at 03:15 PM, Rainer Weikusat rweiku...@mssgmbh.com said: 'mathematics' (an essentially outdated write-only programming language dating back to the times when humans had to perform computations themselves) ROTF,LMAO! You obviously don't have a clue as to what Mathematics means. Free hint: it doesn't mean Arithmetic. You obviously don't have any sense of humour. But don't let this trouble you. -- http://mail.python.org/mailman/listinfo/python-list
Re: lang comparison: in-place algorithm for reversing a list in Perl, Python, Lisp
Xah Lee xah...@gmail.com writes: [...] similarly, in perl, either one require POSIX; floor(x/y); the require POSIX instead of Math is a quirk. But even, floor should really be builtin. or using a perl hack int(x/y) all of the above are quirks. They rely on computer engineering by- products (such as int), Integral numbers are not 'a computer engineering byproduct'. or rely on the lang's idiosyncrasy. One easy way to measure it is whether a programer can read and understand a program without having to delve into its idiosyncrasies. Problem with these lang idioms is that it's harder to understand, and whatever advantage/optimization they provide is microscopic and temporary. It's hard to understand for someone who knows only mathematical idiosyncrasies and who is also convinced that this should really be more than enough for a lifetime. But that's not some kind of 'natural knowledge' people just happen to have but systematically drilled into pupils from a very early age, despite most of them won't ever have any use for any of it insofar it goes beyond + - * /. [...] idiomatic programing, is a bad thing. If you have to use something (like a particular programming language) but you resent learning how to use it and rather make lofty excuses, chances are that you are rather a lazy f*cker than a great philosopher ... -- http://mail.python.org/mailman/listinfo/python-list
Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
Xah Lee xah...@gmail.com writes: A excerpt from the new book 〈Modern Perl〉, just published, chapter 4 on “Operators”. Quote: «The associativity of an operator governs whether it evaluates from left to right or right to left. Addition is left associative, such that 2 + 3 + 4 evaluates 2 + 3 first, then adds 4 to the result. Exponentiation is right associative, such that 2 ** 3 ** 4 evaluates 3 ** 4 first, then raises 2 to the 81st power. » LOL. Looks like the perl folks haven't changed. Fundamentals of serious math got botched so badly. Let me explain the idiocy. It says “The associativity of an operator governs whether it evaluates from left to right or right to left.”. Ok, so let's say we have 2 operators: a white triangle △ and a black triangle ▲. Now, by the perl's teaching above, let's suppose the white triangle is “right associative” and the black triangle is “left associative”. Now, look at this: 3 △ 6 ▲ 5 seems like the white and black triangles are going to draw a pistol and fight for the chick 6 there. LOL. As the perlop manpage would have told you, Operator associativity defines what happens if a sequence of the same operators is used one after another Since this is not the case in your example, it doesn't seem to be applicable here. Also, the Perl I'm aware doesn't have 'white triangle' and 'black triangle' operators and it also doesn't have operators of equal precedence and different associativity. It can't, actually, since there would be no way to evaluate an expression like the mock one you invented above. Lastly, that something happens to be in one way or another way in the completely arbitrary set of rules and conventions commonly referred to as 'mathematics' (an essentially outdated write-only programming language dating back to the times when humans had to perform computations themselves) doesn't mean it is of any relevance anywhere else just because of this, no matter how dear it might be to lots of people. -- http://mail.python.org/mailman/listinfo/python-list
