Using Python for programming algorithms

[Vicent Giner]

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

[Colin J. Williams]

Vicent Giner wrote:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

The usual answer is that development
time is more important than running time.

Since you are likely to be using arrays,
you might look at numpy, where the
number crunching is using compiled C code.

>
* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Try Google with Python and your area of
interest. You could well find
Python-based packages which meet your needs.

>
Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

Good luck.

Colin W.

[castironpi]

On May 17, 5:32*pm, Vicent Giner <[e-mail]:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

You're hearing from 'impossible and useless'-- neither operations.

'Stacks' are pretty important to Python (there is a Stackless Python,
I understand), which makes persistence a little more handy. It's
still a computer and still a language. You may be asking how well its
best speakers know, and look at that, I can't tell you. Some of the
fundamentals of Python may be unexplored to date, as its from the 90s,
and stacks are elements.

I, for one, will assume you're interested in control operations, which
yes Python has, and control is important. The standard library is a
good size to me (I wouldn't go doubling). There's a ready graphics
module. There are code-primitive literals, including lists -and- a
tuple. I think you're looking for the selling points of dynamic
assignment (a.barproperty= 'unheardof'), typefreeness (a= [2,'bcd']),
dynamic execution (exec('print 2'), which promotes a possibility of
self-referentiality), type-aware function pointers, variable-length
procedure arguments, and platform independence.

I think you just asked at the right time. Yes that's an impressive
list.

There is one catch to Python, of the importance of which of the powers
that be, I am unaware. But I do know what you are liable to find on
the newsgroup. Now, with thousands of dollars of institution time on
the money, what control? I will be tentatively assuming that you are
not covertly comparing other languages. I don't think you'll like it
if you're unwise.

[sturlamolden]

On May 18, 12:32 am, Vicent Giner <[e-mail]:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

First of all: whatever you do, use NumPy for all numerical work (and
possibly Scipy). Remember that Python with NumPy tend to be faster
than Matlab. Anything that applies to Matlab regarding vectorization
for speed also applies to NumPy.

If your program runs too slowly, try to use the psyco jit compiler
first. If that doesn't help, try one of the following:

- use Cython or Pyrex and compile your (modified) Python code
- inline C++ using scipy.weave
- write a function in C and call it using ctypes
- write a function in Fortran and make it callable from Python using
f2py

Usually, only small bottlenecks matter when it comes to overall
performance. It is also notoriously difficult to guess where they are.
Therefore: write everything in Python first, then profile your code to
identify bottlenecks. Only important bottlenecks need to be translated
to Pyrex, C or Fortran.

http://www.scipy.org/PerformancePython

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context.

Google NumPy, SciPy, Matplolib and Sage.

NASA uses Python to process image data from the Hubble telescope.

Thank you in advance.

[Henrique Dante de Almeida]

On May 17, 7:32*pm, Vicent Giner <[e-mail]:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

I guess that python is not a good language for that. Algorithms
implemented in plain python are many times slower than C ones
(hundreds ?). In practice, algorithms are written in C and wrapped in
python. I have near zero experience in operations research, but once I
looked for linear programming toolkits for python and IIRC, I only
could find a trivial wrapper for glpk (called pulp).

My opinion: choose compiled or byte compiled languages. Choose the
language paradigm that best suit the algorithms.

[inhahe]

what little I know:

The numbers I heard are that Python is 10-100 times slower than C. So use
Python if you can wait 10-100 times longer. Although it won't really be
that slow using numpy and/or psyco.

Python seems to have a really extensive reportoire of modules available for
it. Although I don't know about things in the math field. If what you want
is obscure enough, then you might find it for C/C++ and not Python. You
might find out in a few seconds by googling.

The advantage to Python (other than production time), is that it would be a
lot simpler and more readable simply as a syntax for conveying algorithms.
It would be like pseudo-code... but runnable. ;)

[Lie]

On May 18, 5:32 am, Vicent Giner <[e-mail]:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

It is slower than a goodly written C code. C codes might be slower
than Python if the writer of C isn't very familiar with C, on the
other hand Python's implementation of things like list, dictionary,
sets, etc are a very optimized piece of code (some says it's the most
fine tuned implementation in the world) and a sloppily written array/
dict/sets implementation in C might be slower than Python.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Why not ask your peers? AFAIK (since I'm not a researcher, just a high-
school student with a "too much time" to program, I'm not even
familiar with Operation Research), in a Operation Research context (as
I understand it from wikipedia) the important thing is the algorithm
instead of pure speed, and codes are written just to describe the
algorithm you're devising. So any programming language that isn't an
esoteric language (like Whitespace or Brainfuck) would not be
considered a "just funny".

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

On May 18, 11:37*am, Dennis Lee Bieber <[e-mail]:

On Sat, 17 May 2008 20:25:18 -0700 (PDT), Henrique Dante de Almeida
<[e-mail] the following in comp.lang.python:

*My opinion: choose compiled or byte compiled languages. Choose the
language paradigm that best suit the algorithms.

* * * * Python IS byte compiled -- that's what .pyc and .pyo filescontain
(strangely though, one must specify a command line argument to get the
"optimized" .pyo, rather than the .pyc with debugging data embedded).

Just to note, currently, "optimized" python code (using -O or -OO)
does very little to make your code goes faster as it doesn't (yet) do
anything but removing docstrings. The -O(ptimized) flags is reserved
to make it possible to add optimizations that might make some features
unavailable or behave differently (such as the docstrings removal that
breaks codes that uses __doc__).

[dmitrey]

Along with numpy & scipy there is some more Python scientific soft
worse to be mentioned:

http://scipy.org/Topical_Software
http://pypi.python.org/pypi?:action=...show=all&c=385

On 18 ôÒÁ, 06:25, Henrique Dante de Almeida <[e-mail]:

once I
looked for linear programming toolkits for python and IIRC, I only
could find a trivial wrapper for glpk (called pulp).

You could be interested in OpenOpt, it has connections to LP solvers
glpk, cvxopt's one and lp_solve (former & latter allows handling MILP
as well)

http://scipy.org/scipy/scikits/wiki/LP

[sturlamolden]

On May 18, 5:46 am, "inhahe" <[e-mail]:

The numbers I heard are that Python is 10-100 times slower than C.

Only true if you use Python as if it was a dialect of Visual Basic. If
you use the right tool, like NumPy, Python can be fast enough. Also
note that Python is not slower than any other language (including C)
if the code is i/o bound. As it turns out, most code is i/o bound,
even many scientific programs.

In scientific research, CPU time is cheap and time spent programming
is expensive. Instead of optimizing code that runs too slowly, it is
often less expensive to use fancier hardware, like parallell
computers. For Python, we e.g. have mpi4py which gives us access to
MPI. It can be a good advice to write scientific software
parallelizable from the start.

I learned Pascal my first year in college. When I started programming
Matlab, I brought with me every habits of a novice Pascal programmer.
Needless to say, my programs ran excruciatingly slow. I learned C just
to write faster "mex" extensions for Matlab. But eventually, my skills
improved and I found that my Matlab programs did not need C anymore.
It took me almost 3 years to unlearn the bad habits I had acquired
while programming Pascal. It is very easy to blame the language, when
in fact it is the programmer who is not using it properly.

[David C. Ullrich]

On Sat, 17 May 2008 15:32:29 -0700 (PDT), Vicent Giner
<vg****@gmail.comwrote:

>Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

Other people have said things about how to use Python
effieiently. Something that seems relevant that I don't
see mentioned:

Are you going to be doing research _about_ the
algorithms in question or is it going to be research
_using_ these algorithms to draw conclusions
about other things?

Most of the replies seem to be assuming the latter.
If it's the former then Python seems like definitely
an excellent choice - when you have want to try
something new it will be much faster trying it
out in Python, when you write up the results
there will be no need for pseudo-code as a
guide to the real code because the Python
will be just about as easy to read as the
pseudo code would be, etc.

>The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

David C. Ullrich

[sturlamolden]

On May 18, 4:20 pm, David C. Ullrich <[e-mail]:

Are you going to be doing research _about_ the
algorithms in question or is it going to be research
_using_ these algorithms to draw conclusions
about other things?

Most of the replies seem to be assuming the latter.
If it's the former then Python seems like definitely
an excellent choice - when you have want to try
something new it will be much faster trying it
out in Python,

I second this. Hence my previous statement that "In scientific
research, CPU time is cheap and time spent programming is expensive."
If it was not clear what I meant, your post can serve as a
clarification. But whether Giner is 'developing' or 'using'
algorithms, he should value his own labour more than the CPU's. CPU
labour (i.e. computation) is very cheap. Manual labour (i.e.
programming) is very expensive. He may in any case benefit from using
Python. Today, the preferred computer language amount scientists is
not Fortran77, but various high-level languages like Matlab, S, IDL,
Perl and Python.

A related question is: How much 'speed' is really needed? If Giner is
analyzing datasets using conventional statistics (ANOVA, multiple
regression, etc.), when will Python (with NumPy) cease to be
sufficient? In my experience, conventional statistics on a dataset of
100,000 or 1,000,000 samples can be regarded child's play on a modern
desktop computer. One really need HUGE amounts of data before it's
worthwhile to use anything else. If one can save a couple of seconds
CPU time by spending several hours programming, then the effort is not
just futile, it's downright wasteful and silly.
Something else that should be mentioned:

The complexity of the algorithm (the big-O notation) is much more
important for runtime performance than the choice of language. If you
can replace a O(N*N) with O(N log N), O(N) or O(1) it is always
adviceable to do so. An O(N*N) algorithm implemented in C is never
preferred over an O(N) algorithm written in Python. The only time when
C is preferred over Python is when N is large, but this is also when
O(N*N) is most painful. Pay attention to the algorithm is things are
running unbearably slow.

Python has highly tuned datatypes like lists, dicts and sets, which a
C programmer will have a hard time duplicating. This also applies to
built-in algorithms like 'timsort'. qsort in the C standard library or
anything a C programmer can whip up within a reasonable amount of time
simply doesn't compare. C vs. Python benchmarks that doesn't take this
into account will falsely put Python in a bad light.

[Jaap Spies]

Vicent Giner wrote:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

* I don't know how likely it is to find libraries in Python related to
my research field.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

You definitely should take a look at Sage: http://www.sagemath.org/

This may offer all you need, based on Python integrating a lot of
other programs!

Jaap

[Bruno Desthuilliers]

Henrique Dante de Almeida a écrit :

On May 17, 7:32 pm, Vicent Giner <[e-mail]:

>Hello.

(snip)

>However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

(snip)

I guess that python is not a good language for that.

(snip)

My opinion: choose compiled or byte compiled languages.

Slightly OT (ie : not talking about computation-heavy alorgithm being
better implemented in C then wrapped in Python - this seems quite
obvious) but just a couple facts:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

[Bruno Desthuilliers]

Vicent Giner a écrit :

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language

cf my answer to you and Henrique on this.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

Then use it.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

In which way is this a problem here ? I thought your thesis was about
algorithm, not about implementation optimisation ? And if it's the
later, then even C might sometimes be too high level - you should drop
to assembly language.

* I don't know how likely it is to find libraries in Python related to
my research field.

I can't tell but you'd be surprised by the quantity of available Python
libs.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Don't know if this answers your question, but it seems that at least
some authors consider it a good choice:
http://www.oreilly.com/catalog/9780596529321/

All code examples in this books are in Python - very badly written
Python, alas...

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Hem... Obviously, most people here will have a little biased, you know ?-)

[Tim Golden]

Bruno Desthuilliers wrote:

2/ actually, all known Python implementations compile to byte-code.

In curiosity, did your "actually" mean, in the French sense, "at the moment"
or, in the English sense, "in contrast to something stated earlier"? Or maybe both?

TJG

[Bruno Desthuilliers]

Tim Golden a écrit :

Bruno Desthuilliers wrote:

>2/ actually, all known Python implementations compile to byte-code.

In curiosity, did your "actually" mean, in the French sense, "at the
moment" or, in the English sense, "in contrast to something stated
earlier"? Or maybe both?

I mainly intented it to be understood in the English sense - but taking
it the French way would be ok too.

[Roel Schroeven]

Bruno Desthuilliers schreef:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right. But I'm still inclined
to disagree with it, since the practical reality is different. Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two, largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

C OTOH was designed to be compiled to assembly code (or directly to
machine code) and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

I love Python, but IMHO it's a bit silly to maintain that the fact that
Python compiles to byte code instead of assembly code/machine code is
purely a matter of implementation; on the contrary, I believe it's a
result of its design. I also think that there's a large difference
between byte code and machine code (in Python's case; I haven't looked
at other languages), and that it's a bit silly to try to trivialize that
difference.

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov

Roel Schroeven

[Diez B. Roggisch]

Roel Schroeven wrote:

Bruno Desthuilliers schreef:

>1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right. But I'm still inclined
to disagree with it, since the practical reality is different. Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two, largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

C OTOH was designed to be compiled to assembly code (or directly to
machine code) and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

I love Python, but IMHO it's a bit silly to maintain that the fact that
Python compiles to byte code instead of assembly code/machine code is
purely a matter of implementation; on the contrary, I believe it's a
result of its design. I also think that there's a large difference
between byte code and machine code (in Python's case; I haven't looked
at other languages), and that it's a bit silly to try to trivialize that
difference.

I strongly disagree. See the Java which is compiled to bytecode
*explicitly*, jet the JVM-bytecode is closer to Python than to what C++ is
compiled to. But then, it's possible to have JIT-compilers that bring
machine code back into the picture.

And see python + psyco as JIT.

And OTOH see Objective-C and it's runtime for an example of a
machine-code-compiled language that still has huge dynamic runtime parts.

All these blur the image extremely and make Bruno's point: compilation is an
artifact, not some inherent property of a language.

Diez

[Henrique Dante de Almeida]

On May 19, 6:52*am, Bruno Desthuilliers <bruno.
[e-mail]:

Henrique Dante de Almeida a écrit :

On May 17, 7:32 pm, Vicent Giner <[e-mail]:

Hello.

(snip)

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

(snip)

*I guess that python is not a good language for that.

(snip)

*My opinion: choose compiled or byte compiled languages.

Slightly OT (ie : not talking about computation-heavy alorgithm being
better implemented in C then wrapped in Python - this seems quite
obvious) but just a couple facts:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

Yes, I was actually referring to statically typed JIT-compiled
languages. Sorry about that, blame the beers that entered my digestive
system that night. :-P

[Henrique Dante de Almeida]

On May 19, 7:03*am, Bruno Desthuilliers <bruno.
[e-mail]:

Vicent Giner a écrit :

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language

cf my answer to you and Henrique on this.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, *but I like Python more.

Then use it.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

In which way is this a problem here ? I thought your thesis was about
algorithm, not about implementation optimisation ? And if it's the
later, then even C might sometimes be too high level - you should drop
to assembly language.

* I don't know how likely it is to find libraries in Python related to
my research field.

I can't tell but you'd be surprised by the quantity of available Python
libs.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Don't know if this answers your question, but it seems that at least
some authors consider it a good choice:http://www.oreilly.com/catalog/9780596529321/

All code examples in this books are in Python - very badly written
Python, alas...

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Hem... Obviously, most people here will have a little biased, you know ?-)

I agree with what most people here said, that the language doesn't
really matter, etc., but that simply does not apply to the specific
case of optimization research.

The little I know about optimization, even trivial problems may be
hairy problems. Naïve implementations simply don't finish and the
performance bottlenecks are not necessarily in the numeric computation
algorithms (so numpy doesn't help much here). If the guy is doing
research on that, it possible that he will work with thousands (or
millions) of weird constraints.

I'm pretty sure about that: when the algorithms take 4 hours to test
a single execution, you value processor time.

The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

[Robin Becker]

Vicent Giner wrote:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

........

>

I programmed several large optimization problems in python. Mostly I used the
old numeric extension for the optimization parts eg vector calculations matrix
inversions etc etc, but I think numpy is used now. Since most of the work was
performed in the C extension we didn't really notice the 'slowness' of python's
interpreter.
--
Robin Becker

[Vicent Giner]

On May 19, 6:11 pm, Henrique Dante de Almeida <[e-mail]>
wrote:

On May 19, 7:03 am, Bruno Desthuilliers <bruno.

I'm pretty sure about that: when the algorithms take 4 hours to test
a single execution, you value processor time.

Yes, of course, but that should mean that I have to do it better, in
the programming step (I would have to re-program or re-implement my
algorithm). And I think the problem would be the same in any other
language, wouldn't it?

The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

Are there such toolkits in other languages? I am not sure they exist
in C, for example.

By the way, is it possible (and easy) to call a C function from a
Python program??

[Lou Pecora]

In article <hi******************@newsfe14.ams2>,
Roel Schroeven <rs****************@fastmail.fmwrote:

Bruno Desthuilliers schreef:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right. But I'm still inclined
to disagree with it, since the practical reality is different. Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two, largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

C OTOH was designed to be compiled to assembly code (or directly to
machine code) and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

But how about this C/C++ interpreter. Dr. Dobbs article:
http://www.ddj.com/cpp/184402054. Title and first two paragraphs:

Ch: A C/C++ Interpreter for Script Computing
Interactive computing in C

Ch is a complete C interpreter that supports all language features and
standard libraries of the ISO C90 Standard, but extends C with many
high-level features such as string type and computational arrays as
first-class objects.

For some tasks, C and its compile/ link/execute/debug process are not
productive. As computer hardware becomes cheaper and faster, to be
productive and cost effective, script computing in C/C++ can be an
appealing solution. To this end, we have developed Ch, an embeddable
C/C++ interpreter for cross-platform scripting, shell programming, 2D/3D
plotting, numerical computing, and embedded scripting [1].

--
-- Lou Pecora

[bruno.desthuilliers]

On 19 mai, 15:30, Roel Schroeven <[e-mail]>
wrote:

Bruno Desthuilliers schreef:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right.

"In theory" ??? Heck, both points above are mere facts. Well, I may
accept that the 2nd one is a bit overgeneralized, since IIRC there's
an experimental Python to javascript "compiler" in Pypy, but...

But I'm still inclined to disagree with it, since the practical reality is different.

Do you mean that how source code written in a language (that is : a
grammar + a syntax) finally become a set of instructions executed by
a CPU depends on the language (I repeat : a grammer + a syntax), and
not on a piece of software turning the source code into something that
can actually be executed by the CPU ? Or that there exists a (working
and usable) implementation of the Python language that does not use an
intermediate byte-code compilation ? If the latest, I'd happly
recognize my error if proven wrong. But on the first point, I'm afraid
that, well, a fact is a fact is a fact.

Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two,

Obviously, yes - at least for all assembly language I've seen so far.
But whoever said otherwise ?

largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

Nope. The facts are that
1/ Python (the language) has *not* been designed with ease of
implementation of an optimizing native-code compiler in mind, and
2/ CPython (the first and reference implementation) has been designed
to use a byte-code + VM scheme

C OTOH was designed to be compiled to assembly code (or directly to
machine code)

Note quite. C has been designed to make it as easy as possible to
write either a C to assembly or C to native binary code compiler.

and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

There's at least one (possibly incomplete) C interpreter. FWIW, it
would not be harder (and possibly simpler) to write a byte-code+VM
based C implementation than it is to write CPython, Jython or
IronPython. The point is that it's just useless - C is a (very) low-
level language, and the only reason to use C is that you'll find a
pretty good optimizing native-code compiler on almost any platform -
sometimes even before the CPU physically exists.

I love Python, but IMHO it's a bit silly to maintain that the fact that
Python compiles to byte code instead of assembly code/machine code is
purely a matter of implementation; on the contrary, I believe it's a
result of its design.

There's a very naive belief we saw every here and then here, which is
that "Python would be faster if it was compiled to native code". The
point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.
FWIW, even Java with it's brain-dead static type-system gained more
from JIT compilation in the VM than from being directly compiled to
native code.

[1] not that I would personnaly be able to do so in a reasonable
amount of time, but given how many talented programmers have been and
are still working on making as fast as possible Python implementions,
it seems obvious that such a thing would already exists if there was
any point working on it.

I also think that there's a large difference
between byte code and machine code

No ? Really ? Now *this* is a scoop, you know ? <g>

(in Python's case; I haven't looked
at other languages), and that it's a bit silly to try to trivialize that
difference.

I'm not trying to "trivialize" anything. I'm just getting fed up with
this "Python is an interpreted and therefore slow language" non-
sense. Python is a language, and as such is neither slow nor fast nor
interpreted nor compiled nor <insert any implementation related stuff
here>. And while CPython is not blazingly fast for computation-heavy
stuff, it's not because it is "interpreted" - which it is not for a
strict definition of "interpreted", but anyway... - but because
*optimizing* execution of an highly dynamic language is nothing,
well, err, trivial.

[bruno.desthuilliers]

On 19 mai, 18:11, Henrique Dante de Almeida <[e-mail]:

On May 19, 7:03 am, Bruno Desthuilliers <bruno.

[e-mail]:

Vicent Giner a écrit :

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language

cf my answer to you and Henrique on this.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

Then use it.

The main drawbacks I see to using Python are these:

* As far as I understand, the fact that Python is not a compiled
language makes it slower than C, when performing huge amounts of
computations within an algorithm or program.

In which way is this a problem here ? I thought your thesis was about
algorithm, not about implementation optimisation ? And if it's the
later, then even C might sometimes be too high level - you should drop
to assembly language.

* I don't know how likely it is to find libraries in Python related to
my research field.

I can't tell but you'd be surprised by the quantity of available Python
libs.

* I know Python is a "serious" and mature programming language, of
course. But I do not know if it is seen as "just funny" in a research
context. Is Python considered as a good programming language for
implementing Operations Research algorithms, such as heuristics and
other soft-computing algorithms?

Don't know if this answers your question, but it seems that at least
some authors consider it a good choice:http://www.oreilly.com/catalog/9780596529321/

All code examples in this books are in Python - very badly written
Python, alas...

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Hem... Obviously, most people here will have a little biased, you know ?-)

I agree with what most people here said, that the language doesn't
really matter, etc., but that simply does not apply to the specific
case of optimization research.

The little I know about optimization, even trivial problems may be
hairy problems. Naïve implementations simply don't finish and the
performance bottlenecks are not necessarily in the numeric computation
algorithms (so numpy doesn't help much here). If the guy is doing
research on that, it possible that he will work with thousands (or
millions) of weird constraints.

I'm pretty sure about that: when the algorithms take 4 hours to test
a single execution, you value processor time.

I'm no expert here, but this sounds like a sensible argument to me.

OTHO, if the OP ends up spending more time writing boilerplate code
and fighting with gory implementation details than working on the
algorithm themselves, he might find than relative difference between
two possible algorithms (like one takes 4 hours and the second take 2
1/2 hours, but each took less than one hour to implement) is much more
important than having the first one taking 4 minutes, the second 2 1/2
minutes, and each having take 15 days to write and debug...

The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

There's at least Psyco (if you're willing and able to restrict
yourself from using some of the most dynamic parts of Python - which
might not be a problem here). One could also mention stuff like Pyrex
and Cython.

[bruno.desthuilliers]

On 19 mai, 20:07, Vicent Giner <[e-mail]:

On May 19, 6:11 pm, Henrique Dante de Almeida <[e-mail]>
wrote:

(snip)

The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

Are there such toolkits in other languages? I am not sure they exist
in C, for example.

Well... They do - they are called 'C compilers' !-) As Roel Schroven
mentioned - and he is at least partially right on this point - C has
been designed to make optimizing C compiler not to hairy to write.

By the way, is it possible (and easy) to call a C function from a
Python program??

Possible, yes, indeed. Easy depends on your definition of easiness,
but going down to C for computation-heavy performance-critical parts
of a program or library is not that uncommon.

[bruno.desthuilliers]

On 19 mai, 17:53, Henrique Dante de Almeida <[e-mail]:

(snip)

Yes, I was actually referring to statically typed JIT-compiled
languages. Sorry about that, blame the beers that entered my digestive
system that night. :-P

for beer in beers:
if beer.entered_henrique_digestive_system_last_night:
beer.blame()

!-)

[Henrique Dante de Almeida]

On May 19, 3:07*pm, Vicent Giner <[e-mail]:

>
Yes, of course, but that should mean that I have to do it better, in
the programming step (I would have to re-program or re-implement my
algorithm). And I think the problem would be the same in any other
language, wouldn't it?

The idea is that a C version of the same program could take, eg. 0,4
hours. But I think we have an authoritative answer here, see Robin
Becker's post (even though he programmed the problem, not the
algorithm). :-)

Are there such toolkits in other languages? I am not sure they exist
in C, for example.

I'm sure there are a lot of toolkits for linear programming (can't
tell about other solvers). glpk is the GNU implementation. It even has
its own built-in language (Mathprog). Someone posted an interesting
link of a python wrapper: "OpenOpt"

http://scipy.org/scipy/scikits/wiki/OpenOpt

It supports many solvers. It may be interesting for you, since there
are some non-linear and "global" problem solvers:

http://scipy.org/scipy/scikits/wiki/OOClasses

By the way, is it possible (and easy) to call a C function from a
Python program??

Yes. The easiest way I know of is using SWIG. People will recommend
you Cython too.

[Henrique Dante de Almeida]

On May 19, 5:25*pm, "[e-mail]"
<[e-mail]:

There's at least one (possibly incomplete) C interpreter. FWIW, it
would not be harder (and possibly simpler) to write a byte-code+VM
based C implementation than it is to write CPython, Jython or

You may (right now, readily, without experimental software) compile C
to, for example, llvm bytecode, interpret it in the VM, JIT-compile
it, native-compile it, etc. There's also experimental support for
compiling C to the JVM.

Notice that you usually want to optimize C code, so it will be harder
than writing a python interpreter.

IronPython. The point is that it's just useless - C is a (very) low-

It's not useless. Consider that you may distribute your C application
in byte-code instead of native code and during the installation
process, it is native compiled and optimized exactly to your
architecture (like a better "Gentoo", with the compilation split
between you and the user).

point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.

That's the job of pypy folks. And they are getting there. They use a
python subset, called RPython:

http://morepypy.blogspot.com/2008/01...er-than-c.html
(note: the test in the site compares garbage collection speed)

BTW, here's how to compile RPython to (optimized) native code:
http://codespeak.net/pypy/dist/pypy/...one-howto.html

And here is the document that talks about all that:
http://codespeak.net/pypy/dist/pypy/...anslation.html

I'm not trying to "trivialize" anything. I'm just getting fed up with
this "Python is an interpreted and therefore slow language" non-
sense. *Python is a language, and as such is neither slow nor fast nor

I'm sorry for creating all those offtopic posts. I feel so ashamed :-
(. Well, not really. :-P

My suggestion was to use code suitable for optimization (not
considering things that you'd need to worry about the way you write
code, like RPython, or psyco). That's all. :-)

[Henrique Dante de Almeida]

On May 19, 5:35*pm, "[e-mail]"
<[e-mail]:

*The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

There's at least Psyco (if you're willing and able to restrict
yourself from using some of the most dynamic parts of Python - which
might not be a problem here). *One could also mention stuff like Pyrex
and Cython.

I meant toolkits for "optimization problems", not "code
optimization".

[Henrique Dante de Almeida]

On May 19, 5:46*pm, "[e-mail]"
<[e-mail]:

On 19 mai, 17:53, Henrique Dante de Almeida <[e-mail]:

(snip)

*Yes, I was actually referring to statically typed JIT-compiled
languages. Sorry about that, blame the beers that entered my digestive
system that night. :-P

for beer in beers:
* if beer.entered_henrique_digestive_system_last_night:
* * beer.blame()

!-)

???

beers += [Beer.random()]

[Bruno Desthuilliers]

Henrique Dante de Almeida a écrit :

On May 19, 5:35 pm, "[e-mail]"
<[e-mail]:

>> The situation would be simpler if there were good well-known toolkits
for optimization in python (like numpy for matrix operations), but
that's not the case.

There's at least Psyco (if you're willing and able to restrict
yourself from using some of the most dynamic parts of Python - which
might not be a problem here). One could also mention stuff like Pyrex
and Cython.

I meant toolkits for "optimization problems", not "code
optimization".

oops, sorry.

[Ivan Illarionov]

On Mon, 19 May 2008 08:53:11 -0700, Henrique Dante de Almeida wrote:

On May 19, 6:52Â*am, Bruno Desthuilliers <bruno.
[e-mail]:

>Henrique Dante de Almeida a écrit :

On May 17, 7:32 pm, Vicent Giner <[e-mail]:
Hello.

(snip)

>However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

(snip)

Â*I guess that python is not a good language for that.

(snip)

Â*My opinion: choose compiled or byte compiled languages.

Slightly OT (ie : not talking about computation-heavy alorgithm being
better implemented in C then wrapped in Python - this seems quite
obvious) but just a couple facts:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

Yes, I was actually referring to statically typed JIT-compiled
languages. Sorry about that, blame the beers that entered my digestive
system that night. :-P

[beer.blame() for beer in beers]

if len(beers) 2:
news_reader.stop_working()

:-)

[Ivan Illarionov]

On Mon, 19 May 2008 11:07:06 -0700, Vicent Giner wrote:
[...]

>
By the way, is it possible (and easy) to call a C function from a Python
program??

Yes.

http://groups.google.com/group/comp....47913a265c348a

-- Ivan

[brad]

Vicent Giner wrote:

The usual answer is that development time is more important than running time.

This depends. Run time is not important until you are asked to scale to
millions or billions of users or computations or large data sets. I've
seen this first hand. Getting results back the same day or sooner may be
important. In cases such as this, I use C or C++... nothing else will
do. Nothing else is as fast. Although I always keep a py version around
for testing and for smaller tasks. Don't get me wrong, I love Python,
but there are times when nothing, but pure, hard speed will do.

[Duncan Booth]

Roel Schroeven <rs****************@fastmail.fmwrote:

C OTOH was designed to be compiled to assembly code (or directly to
machine code) and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

Have you considered Microsoft's C/C++ compiler targetted at .Net. That
compiles to a bytecode known as MSIL which is then interpreted and/or JIT
compiled to machine code.

I love Python, but IMHO it's a bit silly to maintain that the fact that
Python compiles to byte code instead of assembly code/machine code is
purely a matter of implementation; on the contrary, I believe it's a
result of its design. I also think that there's a large difference
between byte code and machine code (in Python's case; I haven't looked
at other languages), and that it's a bit silly to try to trivialize that
difference.

And then there's IronPython which is targetted at .Net. That compiles to a
bytecode known as MSIL which is then interpreted and/or JIT compiled to
machine code.

--
Duncan Booth http://kupuguy.blogspot.com

[Arnaud Delobelle]

brad <by*******@gmail.comwrites:

>Vicent Giner wrote:

>The usual answer is that development time is more important than
running time.

This depends. Run time is not important until you are asked to scale
to millions or billions of users or computations or large data
sets. I've seen this first hand. Getting results back the same day or
sooner may be important. In cases such as this, I use C or
C++... nothing else will do. Nothing else is as fast. Although I
always keep a py version around for testing and for smaller
tasks. Don't get me wrong, I love Python, but there are times when
nothing, but pure, hard speed will do.

Sure. Be careful not to overdose on it though.

--
Arnaud

[sturlamolden]

On May 19, 8:07 pm, Vicent Giner <[e-mail]:

By the way, is it possible (and easy) to call a C function from a
Python program??

Yes it is. You can e.g. use ctypes for that.

[sturlamolden]

On May 19, 10:42 pm, "[e-mail]"
<[e-mail]:

Well... They do - they are called 'C compilers' !-) As Roel Schroven
mentioned - and he is at least partially right on this point - C has
been designed to make optimizing C compiler not to hairy to write.

C has proven very difficult to optimize, particularly because pointer
aliasing prevents efficient register allocation.

Fortran was designed with ease of optimization in mind. Not many years
ago, it was not uncommon for Fortran code to run twice as fast as
equivalent C. C compilers have recently closed on on the gap by
becoming extremely good at what they do. But that is not because C is
easy to optimize. On the contrary.

For serious number crunshing, there is nothing that compares to
Fortran, even today. f2py makes it easy to call Fortran subroutines
from Python.

[Grant Edwards]

On 2008-05-20, Ivan Illarionov <iv*************@gmail.comwrote:

On Mon, 19 May 2008 11:07:06 -0700, Vicent Giner wrote:
[...]

>>
By the way, is it possible (and easy) to call a C function from a Python
program??

Yes.

http://groups.google.com/group/comp....47913a265c348a

Even easier:

http://docs.python.org/lib/module-ctypes.html

--
Grant Edwards grante Yow! I'd like some JUNK
at FOOD ... and then I want to
visi.com be ALONE --

[sturlamolden]

On May 20, 7:24 pm, Grant Edwards <[e-mail]:

>
http://docs.python.org/lib/module-ctypes.html

Also see Cython (or Pyrex if you prefer the original). With Cython it
is easy to call C functions, but Cython also alleviates the need for C
to a great extent. The advantage of Cython over C + ctypes is of
course the readability of Python and the presence of Python built-in
types like strings, dicts and lists. Unfortunately, it is still a bit
difficult to use NumPy ndarrays with Cython or Pyrex. NumPy ndarrays
work very well with ctypes though.

http://www.cython.org/

[Roel Schroeven]

Wow this resulted in far more reactions than I had expected ...

br*****************@gmail.com schreef:

On 19 mai, 15:30, Roel Schroeven <[e-mail]>
wrote:

>Bruno Desthuilliers schreef:

>>1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.
2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right.

"In theory" ??? Heck, both points above are mere facts. Well, I may
accept that the 2nd one is a bit overgeneralized, since IIRC there's
an experimental Python to javascript "compiler" in Pypy, but...

> But I'm still inclined to disagree with it, since the practical reality is different.

Do you mean that how source code written in a language (that is : a
grammar + a syntax) finally become a set of instructions executed by
a CPU depends on the language (I repeat : a grammer + a syntax), and
not on a piece of software turning the source code into something that
can actually be executed by the CPU ?

No, that's not what I said; what I said is that some languages where
designed with in the back of the head the idea that they were going to
be compiled to native code, others to be interpreted, and others to be
compiled to byte code.

Wikipedia says about C that "its design goals were for it to be compiled
using a relatively straightforward compiler, provide low-level access to
memory, provide language constructs that map efficiently to machine
instructions, and require minimal run-time support". To me, that very
strongly suggests that it was meant to be compiled to native code. It's
called "portable assembly" for a reason. You *can* make it work in
another way, and I suppose that it *is* done, but those implementations
are far in the minority.

As for Python, until the advent of PyPy all implementations I known used
a virtual machine (CPython, Jython, IronPython). And PyPy is still
experimental as far as I know.

So yes, the transformation method from source code to something that the
CPU understands depends on your tools. But if you want to get work done,
the most common method by far for C is to use a toolchain that compiles
to native code and for Python a byte code compiler + virtual machine.
With possibly a JIT compiler, that's true.

>Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two,

Obviously, yes - at least for all assembly language I've seen so far.
But whoever said otherwise ?

Whenever someone says that Python is interpreted, you respond saying
that that's not true, since it's compiled to byte code. Correct of
course, but somehow it appears to me that you imply that that makes
Python closer to a C-like language than to an interpreted language, and
that's not correct (IMO). If that's just a misinterpretation by me, I
apologize.

> largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

Nope. The facts are that
1/ Python (the language) has *not* been designed with ease of
implementation of an optimizing native-code compiler in mind, and
2/ CPython (the first and reference implementation) has been designed
to use a byte-code + VM scheme

Isn't that more or less the same as what I said?

Maybe I don't make enough distinction between Python the language and
CPython the implementation, but Python development does happen on the
CPython implementation (Python 3.0 alpha releases are CPython releases,
for example).

>

>C OTOH was designed to be compiled to assembly code (or directly to
machine code)

Note quite. C has been designed to make it as easy as possible to
write either a C to assembly or C to native binary code compiler.

I find it hard to believe that during the development of C Dennis
Ritchie was considering any other mode of operation than compilation to
assembly or machine code. I might be wrong of course.

>and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

There's at least one (possibly incomplete) C interpreter.

I'd like to call that the exception that confirms the rule.

There's a very naive belief we saw every here and then here, which is
that "Python would be faster if it was compiled to native code". The
point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.

I admit I'm guilty of that belief. I know it's true what you say, but I
do have the more-or-less unconscious reflex 'compiled to native code
== fast'.

I'm just getting fed up with
this "Python is an interpreted and therefore slow language" non-
sense. Python is a language, and as such is neither slow nor fast nor
interpreted nor compiled nor <insert any implementation related stuff
here>. And while CPython is not blazingly fast for computation-heavy
stuff, it's not because it is "interpreted" - which it is not for a
strict definition of "interpreted", but anyway... - but because
*optimizing* execution of an highly dynamic language is nothing,
well, err, trivial.

So you are saying that CPython is relatively slow because Python is a
highly dynamic language. I know that CPython is not Python and Python is
not CPython, but there is a very strong association between the two and
therefore I think it's not really that much wrong to simplify that to
'Python is slow because it is a highly dynamic language (until proven
wrong by PyPy or another fast implementation'.

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov

Roel Schroeven

[Aahz]

In article <g0**********@solaris.cc.vt.edu>, brad <by*******@gmail.comwrote:

>
Run time is not important until you are asked to scale to millions
or billions of users or computations or large data sets. I've seen
this first hand. Getting results back the same day or sooner may be
important. In cases such as this, I use C or C++... nothing else will
do. Nothing else is as fast. Although I always keep a py version around
for testing and for smaller tasks. Don't get me wrong, I love Python,
but there are times when nothing, but pure, hard speed will do.

YouTube?
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

Need a book? Use your library!

[sturlamolden]

On May 20, 3:37 pm, brad <[e-mail]:

seen this first hand. Getting results back the same day or sooner may be
important. In cases such as this, I use C or C++... nothing else will
do. Nothing else is as fast.

Right. Tell that to the Fortran community. And by the way:

http://latticeqcd.blogspot.com/2006/...nd-python.html

[Kay Schluehr]

On 18 Mai, 00:32, Vicent Giner <[e-mail]:

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

If Python doesn't run in production systems execution speed doesn't
matter much. What actually matters when *developing* non-trivial algos
is to partition the dataflow because it might take just long to reach
a certain execution point that is of current interest - and it has to
be reached repeatedly. For each method call one might want to work
with pre-computed data that were serialized in a former run. Given
Pythons flexibility this shall be easy and so it is! The combination
of object pickling/unpickling and using decorators makes this a snap.
Just look at the following simple decorator:

def dump_data(func):
def call(*args, **kwd):
res = func(*args, **kwd)
fl = open("dump_data.pkl", "w")
pickle.Pickler(fl, 0).dump(args[0])
return res
call.__name__ = func.__name__
call.__doc__ = func.__doc__
return call

and the corresponding loader:

def load_obj():
f = open("dump_data.pkl")
return pickle.Unpickler(f).load()

One might decorate an arbitrary object method foo() with dump_data and
resume the activity of the object after foo has been called in another
run by restoring the object with load_obj.

One can further improve this by serializing the test driver when it is
implemented as a generator. This is non-standard though and requires
some work [1] of my own or Stackless Python [2] alternatively.

What I intended to make clear is that Python has many goodies as a
toolbox besides having lots of bindings and being well readable ( the
usual suspects when it comes to advocation in threads like these ).

[1] http://www.fiber-space.de/generator_...tor_tools.html
[2] http://www.stackless.com/

[Paddy]

On May 19, 8:09 pm, Lou Pecora <[e-mail]:

In article <hifYj.43082$[e-mail]2>,
Roel Schroeven <[e-mail]:

Bruno Desthuilliers schreef:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.

2/ actually, all known Python implementations compile to byte-code.

You keep saying that, and in theory you're right. But I'm still inclined
to disagree with it, since the practical reality is different. Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two, largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

C OTOH was designed to be compiled to assembly code (or directly to
machine code) and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

But how about this C/C++ interpreter. Dr. Dobbs article: http://www.ddj.com/cpp/184402054. Title and first two paragraphs:

Ch: A C/C++ Interpreter for Script Computing
Interactive computing in C

Ch is a complete C interpreter that supports all language features and
standard libraries of the ISO C90 Standard, but extends C with many
high-level features such as string type and computational arrays as
first-class objects.

If you still end up chasing pointers to implement your data structures
then its still hampered.

[Paddy]

On May 17, 11:32 pm, Vicent Giner <[e-mail]:

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

Using Python doesn't mean you give up on C! Many of the best
algorithms written in other languages such as C, C++ and Fortran are
pre-wrapped in Python or can be wrapped in a Python interface to
enhance usability, without having to pay Matlab-type prices. You then
make your resulting work easier to reproduce by lowering the cost to
other researchers.

Python is a scripting language. Despite what some may think, it is a
boon, as it means that Pythons designers value its ability to work
well with other languages and systems.

Nothing stops you from exploring algorithm space in Python then re-
implementing in a language closer to assembler - and this may well be
the quicker way to your goal.

- Paddy.

[Bruno Desthuilliers]

Roel Schroeven a écrit :

Wow this resulted in far more reactions than I had expected ...

br*****************@gmail.com schreef:

>On 19 mai, 15:30, Roel Schroeven <[e-mail]>
wrote:

>>Bruno Desthuilliers schreef:

1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.
2/ actually, all known Python implementations compile to byte-code.
You keep saying that, and in theory you're right.

"In theory" ??? Heck, both points above are mere facts. Well, I may
accept that the 2nd one is a bit overgeneralized, since IIRC there's
an experimental Python to javascript "compiler" in Pypy, but...

>> But I'm still inclined to disagree with it, since the practical
reality is different.

Do you mean that how source code written in a language (that is : a
grammar + a syntax) finally become a set of instructions executed by
a CPU depends on the language (I repeat : a grammer + a syntax), and
not on a piece of software turning the source code into something that
can actually be executed by the CPU ?

No, that's not what I said; what I said is that some languages where
designed with in the back of the head the idea that they were going to
be compiled to native code, others to be interpreted, and others to be
compiled to byte code.

I'd put it more simply : some languages were designed with low-level
access and raw performances in mind, and some were'nt. Roel, I'm totally
aware of these issues - on which you're of course right -, but that
doesn't change the fact that a language and it's implementation *are*
distinct things.

(snip)

So yes, the transformation method from source code to something that the
CPU understands depends on your tools.

And you can have different tools using different solutions for a same
language.

But if you want to get work done,
the most common method by far for C is to use a toolchain that compiles
to native code and for Python a byte code compiler + virtual machine.
With possibly a JIT compiler, that's true.

>>Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two,

Obviously, yes - at least for all assembly language I've seen so far.
But whoever said otherwise ?

Whenever someone says that Python is interpreted, you respond saying
that that's not true, since it's compiled to byte code.

Whenever someone says that Python is interpreted, I respond saying that
being interpeted or compiled is not a feature of a language, and that
CPython compiles to byte-code.

Correct of
course,

And that's the point : being correct.

but somehow it appears to me that you imply

I don't imply anything - except eventually that the person I'm
correcting should know better.

that that makes
Python closer to a C-like language than to an interpreted language,

Strange enough, no one calls Java or C# 'interpreted languages', while
they (or, to be more exact, their reference implementations) both use
the same byte-code/VM scheme[1]. You know, the commonly accepted
definition of "byte-code" is "something that is going to be passed to a
virtual machine", not "native binary executable code", so I don't think
this could be really misleading.

Now what you don't seem to get is the difference between pure
interpretation - where each and every statement is parsed and
interpreted again and again - and intermediate byte-code compilation.
Believe me, *this* can make a huge difference wrt/ performances.

Also and FWIW, there are quite a lot of "C-like languages" that are - in
their only or reference implementation - interpreted or compiled to
byte-code. For a definition of "C-like" being "close to the C language's
syntax and grammar" !-)

[1] Oh, and before some nut-case jump in : no, this doesn't imply that
the CPython VM is 'equivalent' to Sun's Java VM or MS CLI/.NET VM.

and
that's not correct (IMO). If that's just a misinterpretation by me, I
apologize.

>> largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.

Nope. The facts are that
1/ Python (the language) has *not* been designed with ease of
implementation of an optimizing native-code compiler in mind, and
2/ CPython (the first and reference implementation) has been designed
to use a byte-code + VM scheme

Isn't that more or less the same as what I said?

Can't you tell the difference ???

Maybe I don't make enough distinction between Python the language and
CPython the implementation, but Python development does happen on the
CPython implementation (Python 3.0 alpha releases are CPython releases,
for example).

>>

>>C OTOH was designed to be compiled to assembly code (or directly to
machine code)

Note quite. C has been designed to make it as easy as possible to
write either a C to assembly or C to native binary code compiler.

I find it hard to believe that during the development of C Dennis
Ritchie was considering any other mode of operation than compilation to
assembly or machine code. I might be wrong of course.

I'm not talking about "development" (which implies implementation), but
about the design of the *language*. Roel, can you define "language" ?

>>and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.

There's at least one (possibly incomplete) C interpreter.

I'd like to call that the exception that confirms the rule.

Which rule ?

Oh, and yes - as a couple persons pointed out, there are actually more
than "one (possibly incomplete) C interpreter" - there are also the
llvm byte-code compiler+VM and the MS CLI C/C++ compiler.

>There's a very naive belief we saw every here and then here, which is
that "Python would be faster if it was compiled to native code". The
point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.

I admit I'm guilty of that belief. I know it's true what you say, but I
do have the more-or-less unconscious reflex 'compiled to native code ==
fast'.

So make a simple test : write a very Q&D cat-like program in Python, C
and Perl, and benchmark the three implementations. The results might
surprise you.

>I'm just getting fed up with
this "Python is an interpreted and therefore slow language" non-
sense. Python is a language, and as such is neither slow nor fast nor
interpreted nor compiled nor <insert any implementation related stuff
here>. And while CPython is not blazingly fast for computation-heavy
stuff, it's not because it is "interpreted" - which it is not for a
strict definition of "interpreted", but anyway... - but because
*optimizing* execution of an highly dynamic language is nothing,
well, err, trivial.

So you are saying that CPython is relatively slow because Python is a
highly dynamic language.

And therefore difficult to optimize.

I know that CPython is not Python and Python is
not CPython, but there is a very strong association between the two

Indeed. CPython is the reference implementation of Python. Like GCC is
the reference implementation of C on linux platforms. etc...

and
therefore I think it's not really that much wrong to simplify that to
'Python is slow because it is a highly dynamic language'

It is definitively wrong. How could a *language* be 'slow' or 'fast' ?

(until proven
wrong by PyPy or another fast implementation'.

You know, Common Lisp is also an highly dynamic language, and there are
now some optimizing native-code Common Lisp compilers that generate very
efficient binary code. It only tooks about 30 years and way more
ressources than CPython ever had to get there...

[Bruno Desthuilliers]

sturlamolden a écrit :

On May 19, 10:42 pm, "[e-mail]"
<[e-mail]:

>Well... They do - they are called 'C compilers' !-) As Roel Schroven
mentioned - and he is at least partially right on this point - C has
been designed to make optimizing C compiler not to hairy to write.

C has proven very difficult to optimize, particularly because pointer
aliasing prevents efficient register allocation.

Does this compare to optimizing something like Python ? (serious
question, but I think I already know part of the answer).

[=?ISO-8859-1?Q?Fr=E9d=E9ric_Degraeve?=]

By the way, is it possible (and easy) to call a C function from a
Python program??

Use SWIG. It's easy, smart and beautiful. After that, you can call C/C+
+ from a lot of scripting languages such as python, R, etc
A lot of open sources projects already use it.

http://www.swig.org/tutorial.html

Boost.Python is also very known (but never tested by myself).

Frédéric