Performance question about math operations

[Delaney, Timothy]

> From: Andrew P. Lentvorski [mailto:bsder at mail.allcaps.org]
> 
> Please give me a *little* credit.  I am aware that Python doesn't do
> constant folding, etc.  In the real code, those constants are 
> variables.
> However, my point was that the floating point operations are 
> sufficiently
> slow *even with constants* that they dominate the variable references.

How could we give you that credit? Most people have never seen you here
before, so we had to base our judgement on your level of understanding on
the code you posted. That code showed no understanding of standard python
optimisations and idioms, so everyone presumed you were a beginning Python
programmer.

If you have *real* code that demonstrates what you want to do you are more
likely to get helpful responses. What you posted was at a beginner's level,
and so you received responses targetted to a beginner.

> What I was hoping to provoke was a discussion about hoisting 
> integer and
> floating point dominated paths into a Python optimization.  
> Or possibly
> looking at the efficiency of the dispatch table for FP and integer
> dominated paths.

There have been *many* discussions about this. For the most advanced
projects, look at:

	http://sourceforge.net/projects/psyco/
	http://homepages.ulb.ac.be/~arigo/psyco/

	http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/

> Terry Reedy <tjreedy at udel.edu> wrote:
> > Use numerical Python extensions which works with arrays of unboxed
> > floats and which only has to interprete +-*/ once each for entire
> 
> Well, I tried that.  I have used both Numeric and SciPy for a circuit
> simulation engine and it works well; it fails for a layout editor.
> Special data structures are required to handle the 2-D region querying
> which is the hallmark of a VLSI layout editor.  (10,000,000 polygons -
> 10^4 difference in coordinate values (.1 um to 1cm))

In that case, you should have mentioned that fact. The standard response to
"This <numeric computation> is too slow in Python" is "Look at the Numeric
extension".

Is there any reason you can't perform the calculations in Numeric, then
transform the result to the data structure you need? For speed you may find
that you need to write a small C extension to Python, which can itself work
with the Numeric package.

The reason that Python is slow at numeric calculations is because it cannot
assume that an object is indeed numeric when it performs the calculation.
Psyco is an attempt to remove this restriction. Pyrex is another attempt,
from a different angle (making it possible to write Python extensions in a
Python-like language).

Tim Delaney