[24119] in Perl-Users-Digest
Perl-Users Digest, Issue: 6313 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 28 00:05:30 2004
Date: Sat, 27 Mar 2004 21:05:04 -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 Sat, 27 Mar 2004 Volume: 10 Number: 6313
Today's topics:
Appreciation for the importance of readability (was: Ch (Cameron Laird)
Re: Choosing Perl/Python for my particular niche (Cameron Laird)
Re: Choosing Perl/Python for my particular niche (Paddy McCarthy)
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 28 Mar 2004 02:32:14 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Appreciation for the importance of readability (was: Choosing Perl/Python for my particular niche)
Message-Id: <106ce9eaed1sk61@corp.supernews.com>
In article <40657D14.3FBE7E82@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
.
[various stuff about
freeware, VNC, ...
that no longer seems
urgent]
.
.
>Python. I've tried to read my own C++ code after half a
>year, and have gained a new appreciation for the importance
>of readability. So I'm still fine-tuning my idea of
>adequate commenting. Since I'm working on my thesis rather
>than commercial code, I don't have large amounts of generic
>C++ library code. Just a big-ish heap of routines/functions
>for the problem that I'm investigating, as the algorithms
>that I choose to try morph.
>
>My impression is that you think Python would be more
>appropriate for my situation. Just wondering if you can
>comment on the merit of having lots of Perl code around. It
>seems to be prevelant in a digital design tool environment.
>It may not matter all that much to me right now, but it
>would be nice to be on the same wavelength as others if I
>find myself in a team situation. As I mentioned, there have
.
.
.
Some scientists are very successful with "slash-and-burn"
techniques. That manifests itself in this area as "con-
science-free" coding: they write whatever programs get
them the results they're after, and don't care that no
one else can reproduce their results, nor can they them-
selves, six months later. A LOT of that goes on.
It makes me uncomfortable. A lesson I've learned over
and over is that computer programs live far longer than
you expect. It pays to do 'em better at the beginning,
'cause you're likely to live with them quite a while.
I'm not a successful scientist, though; odds are long
against me ever being one.
Being "on the same wavelength" is yet another of the
dualities you face. It has its advantages. So does
leadership in establishing new and better ways. You
might never know which is the right choice. Most cer-
tain is that *you* are the one who'll live with the
choices you make.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: Sun, 28 Mar 2004 02:11:40 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <106cd2srpsjq571@corp.supernews.com>
In article <40661C14.8365E058@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
.
.
.
>On the topic of speed, It's surprising to hear that this can be possibly rivaled
>by Perl/Python, considering that even my matlab code is about 10x slower than
>C++. That's with extensive profiling and round-about coding styles to exploit
>vectorization tricks, and no such effort in the C++ code. Some of the
>limitations are pretty fundamential e.g. large speed penalties for invoking
>nonbuiltin functions. Such limitations discourage clear coding practice e.g.
>huge swaths of code to avoid encapsulating some functionality in its own
>function. Together with the sometimes roundabout coding style, it can detract
>from the matlab's high level ease of programming and clarity, especially
>considering that C++ can be brought to a high level with its STL library. And
>this speed disparity shows up despite matlab's mission to develop in a way that
>rivals 3G languages. Speed considerations aside, however, matlab is infinitely
>easier to use and to read. With time, perhaps the limitations will shrink.
>
>This is not to say that Perl/Python will have the same limitations. They are,
>however, more general purpose languages, so I expect that speed is less of a
>priority than in scientific computing (compared to other important priorities).
>Hence, learning curve aside, some time needs to be invested in exploring its
>speed in a realistic scientific applications. For me, this is an option for the
>more distant future rather than the immediate term. I spent quite alot of time
>in this phase with matlab, trying to squeeze out all possible speed before
>conceding that some of the limits were fundamental, at least in the current
>release.
>
>One thing I learned was that speed characterization was not a simple. Many of
>the tasks found in scientific computing are done blistering fast by matlab. It
>is not until you put together a larger application when you start running into
>the limitations. Aside from the speed penalties of calling nonbuiltins,
.
.
.
'Couple of reactions: first, I think it's entirely healthy
for you to focus on finishing your dissertation. Everything
else is and should be subordinate to that. Picking up as
much of Perl as you need to achieve that goal, but not more,
is thoroughly sensible.
Second, be aware that I'm the only one in this thread who has
made explicit claims that it's reasonable to expect Perl- or
Python-based applications to rival those in C++ for
performance. Maybe I'm wrong, or, more charitably, maybe I'm
making assumptions that I've kept implicit. It certainly is
possible to exhibit comparable-looking C and Python programs,
where the former is over a hundred times as fast as the latter.
Still, I'm sticking with my claim: for practical, effective
algorithmic experimentation, PDL, Numpy, and comparable exten-
sions bring 'P' programs' achieved speed up to the level of
C++.
Ultimately, you're right: "speed characterization [is] not
simple."
Perl and Python feel like breaths of fresh air after Matlab
precisely for their scalability and maintainability. Matlab
just doesn't generalize and abstract and express as agilely
as the more general-purpose programming languages.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: 27 Mar 2004 18:14:29 -0800
From: paddy3118@netscape.net (Paddy McCarthy)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <2ae25c6b.0403271814.5d789e9e@posting.google.com>
Hi Fred,
If there are particular C/C++ packages of algorithms that you use then
you might try searching for the package name +python on the web. You
might find someone who has already turned the library into aPython
module.
There are several Scientific libraries for Python that have good
graphing capabilities as well as speed advantages for certain
operations. - Try installing the Enthought Python distribution for
windows at: http://www.enthought.com/python/
Another good page is ScriptEDA:
http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/ - I was using the
gate-level verilog parser a month ago.
On Scripting language choice, I find TCL to be in many EDA tools, but
its datastructures and syntax make it a language I use when I have
to, rather than a language of choice.
Perl IS used a lot in EDA but I like to think of it as being dangerous
in a lot of hands as great Engineers start scripting larger and larger
applications in Perl and usually end up with something that is hard to
maintain and hard to write. Perl does have its sweet spot - I do like
the `perl -p -i -e` mewthod of making sed like alterations to files
in-place, butthe languages support for subroutine arguments - compared
to Pythons; and the need to compute and pass around references to
lists and hashes for simple nested datastructures - things like that
shout small programs only to me.
Python is my language of choice for a large amount of programming in
the EDA field (when given the choince :-).
Perl has a large library, Python has a large library - what you need
to do is do some web searches for libraries in your field to see which
is more appropriate -
When I have to write an algorithm from scratch then I do it in Python.
It does get out of the way and allow me to concentrate on the
algorithm most of the time. (Although I wish it had constrained random
generation of integers like Vera or Specman :-).
I hope I've helped, Paddy.
------------------------------
Date: 28 Mar 2004 03:52:25 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <40664D05.9BB91F46@doe.carleton.ca>
Hi, Paddy,
Wow, there's more information coming in than I expected. Having
a bit of a nonengineering day (at least not at the ground level)
keeping up. I did ask for it.
Paddy McCarthy wrote:
>
> Hi Fred,
> If there are particular C/C++ packages of algorithms that you use then
> you might try searching for the package name +python on the web. You
> might find someone who has already turned the library into aPython
> module.
Actually, verilator (does verilog to SystemC, which is a C++ library
that provides HDL simulation capability) is a Perl-based module.
As for the glue functionality I need to modify the my original verilog
source, there's no specific functionality. I'm still trying to think
of ways in which to modify to code to work around the translation
limitations of verilator. So the filter will be very much ad-hoc.
> There are several Scientific libraries for Python that have good
> graphing capabilities as well as speed advantages for certain
> operations. - Try installing the Enthought Python distribution for
> windows at: http://www.enthought.com/python/
>
> Another good page is ScriptEDA:
> http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/ - I was using the
> gate-level verilog parser a month ago.
Wow. The screen shots on for enthought are impressive. The software at
scriptEDA reminds me that I'm an a newbie in this area. The level to
which interfacing environments and languages have been brought boggles
the mind. I think that I need to take a bite of Perl and/or Python
before I even consider looking at the offerings there with any degree
of appreciation. For the computation engine and post-process/graphing,
I'll stick with C++/matlab for now, due to lack of thesis time, and
because I've got a familiar system (or "idiom"?) setup to use them
together. As I mentioned in another post, I'll start with Perl as
the starting point, and keep tabs on Python, something that is feasible
because of its readability.
> On Scripting language choice, I find TCL to be in many EDA tools, but
> its datastructures and syntax make it a language I use when I have
> to, rather than a language of choice.
>
> Perl IS used a lot in EDA but I like to think of it as being dangerous
> in a lot of hands as great Engineers start scripting larger and larger
> applications in Perl and usually end up with something that is hard to
> maintain and hard to write. Perl does have its sweet spot - I do like
> the `perl -p -i -e` mewthod of making sed like alterations to files
> in-place, butthe languages support for subroutine arguments - compared
> to Pythons; and the need to compute and pass around references to
> lists and hashes for simple nested datastructures - things like that
> shout small programs only to me.
I got the same impression, but there have been other explanations given
in this thread for the unweldiness of big projects, as well as the fact
that this is not universal. Myself, I will be using "P..." for glue
functionality, so I won't run the risk of creating dangerously
unmaintainable code (finger crossed here). Besides, it's for the thesis,
which has to be finished soon, so I won't have the problem of looking
back a ways to figure out code written long ago. By the time I get to
an industrial situation (fingers crossed, since jobs are leaving North
America), I hope to have a bit for breathing time to ramp up on Python.
> Python is my language of choice for a large amount of programming in
> the EDA field (when given the choince :-).
>
> Perl has a large library, Python has a large library - what you need
> to do is do some web searches for libraries in your field to see which
> is more appropriate -
Well...I did it...verilog to SystemC boils down to verilator unless one
has money to shell out. Despite its professed limitations, I am still
astounded to read even the help pages. That degree of sophistication,
for free. Kind of makes the thesis look like small time, though of
course, the challenges are of a different nature.
> When I have to write an algorithm from scratch then I do it in Python.
> It does get out of the way and allow me to concentrate on the
> algorithm most of the time. (Although I wish it had constrained random
> generation of integers like Vera or Specman :-).
>
> I hope I've helped, Paddy.
A great deal. Thanks.
Fred
------------------------------
Date: 28 Mar 2004 04:29:11 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <406655A2.CCC571E@doe.carleton.ca>
Paul McGuire wrote:
>
> "Fred Ma" <fma@doe.carleton.ca> wrote in message
> news:40652B0D.7C313F77@doe.carleton.ca...
> <snip>
> > One thing I expect to have to do is to modify design
> > files. For example, there is a tool which takes ASCII
> > hardware desscription language (HDL) and converts it
> > to a C++ (augmented by hardware simulation library).
> > The translator is freeware, so has limitations which I
> > have to make up for by tweaking the HDL code.
>
> If you eventually find yourself in the Python realm, please look into the
> pyparsing text parsing module, more information at
> http://pyparsing.sourceforge.net/. I have implemented an easily-extended
> 99% Verilog parser using this module, and it may provide some shortcuts for
> you in dealing with your HDL files.
>
> -- Paul McGuire
Hi, Paul,
I took a look at your website. I've decided to go Perl for now,
and ramp up on Python on the side. I think a parser has a higher
level of intelligence than regex'ing, but I hesitate to jump into
it at the moment because thesis time is running out. I may do some
adhoc regex'ing, either with sed/Perl/gvim (it's quick and dirty,
but suitable for the time crunch of my current circumstance, which
is a hard deadline on the thesis). Also, I'm doing the quick-and-
dirty because of limitations of an *existing* verilog parser (and
translator) which I don't want to delve into right now, for the
same reason. But thanks for the heads up. If things work out in
the long run, and I get to know Python, I know there is a verilog
parser to keep an eye out for.
Fred
------------------------------
Date: 28 Mar 2004 04:48:39 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <40665A39.DF0AC455@doe.carleton.ca>
Petri wrote:
>
> In article <40652B0D.7C313F77@doe.carleton.ca>, Fred Ma says...
> > One thing I expect to have to do is to modify design
> > files. For example, there is a tool which takes ASCII
> > hardware desscription language (HDL) and converts it
> > to a C++ (augmented by hardware simulation library).
> > The translator is freeware, so has limitations which I
> > have to make up for by tweaking the HDL code.
>
> The translator, is it doing the Verilog stuff you mention later in the thread?
> Why not check if you can't replace the translator altogether with an existing
> Perl module:
> http://search.cpan.org/search?query=verilog&mode=all
>
> Well, I know nothing about your problem area, but it's a tip in case you hadn't
> thought about checking CPAN.
>
> Petri
Actually, I was spending much of last week installing many
of those tools! The translater (verilator) is Perl-based,
written by Wilson Snyder (author of many of those tools)
and relies on many of those tools. But thanks for the tip...
Fred
------------------------------
Date: 28 Mar 2004 04:43:22 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <406658F5.9F62DF55@doe.carleton.ca>
Jim Keenan wrote:
>
> You are at Carleton University, which was the site of Yet
> Another Perl Conference::Canada in May 2003. So you have an excellent
> pool of local Perl experts to draw upon -- and there are many more not
> far away in Montreal, Toronto and Kitchener/Waterloo. Look them up
> via http://www.pm.org/groups/north_america.html .
Thanks for the pointer, Jim.
Fred
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 6313
***************************************
