[SciPy-dev] genetic algorithm, number theory, filterdesign,zerofinding

Chuck Harris Chuck.Harris at sdl.usu.edu
Thu Apr 11 13:59:44 CDT 2002


> -----Original Message-----
> From: pearu at scipy.org [mailto:pearu at scipy.org]
> Sent: Thursday, April 11, 2002 12:14 PM
> To: scipy-dev at scipy.org
> Subject: RE: [SciPy-dev] genetic algorithm, number theory,
> filterdesign,zerofinding
> On Thu, 11 Apr 2002, Chuck Harris wrote:
> > I've taken a look at the 1-D solvers in CVS. A few comments
> > 
> > 1.	fixed_point computes incorrect roots
> > 2.	they make assumptions on the arguments that are not enforced
> > 3.	none take into account the varying granularity of floating point
> > 4.	newton should probably check for blowup, as this is not uncommon
> > 5.	all the python routines suffer from large overheads. We 
> should go for C.
> > 
> > That said, the routines a pretty quick. I think a good 
> starting point
> > would be to take the simplest and put them in C. I expect this would
> > at least halve the execution time for easy to compute functions.
> How to you feel about Fortran? Actually C is also fine for me.

I don't mind Fortran, and for some things I think it is superior to C, but I find that C compilers are easier to come by on all platforms; I don't much enjoy cygwin. Also, at this point in time C is more familiar to me. For the root finding, it shouldn't be too hard to keep track of reference counting.

> My point is that we should use f2py to generate the 
> interfaces to these C
> (or Fortran, if you have positive feelings about it) routines.
> It has an advantage that you don't need to struggle with the
> details of Python C/API (reference counting, argument checks, etc.)
> All this is supported in f2py generated interfaces. Using 
> f2py saves time
> and bugs. And the f2py generated extension modules are really easy to
> maintain.

I pretty much agree with this. Perhaps it would be nice to have a c2py interface also.

> If you are not familiar with f2py then we can cooperate. You give me
> a native C function and I'll give you an interface for calling this C
> function from Python in no time.

Hmm... f2py handles this?

> > For newton, I don't think the option of using computed 
> derivatives is
> > worth including. There is a slightly higher order of 
> convergence (2 vs
> > 1.4), but this is likely to be swamped in function evaluation time,
> > especially if the function is python and the routine is C.
> Indeed, I have never used  computed derivatives in my real 
> problems. They
> are usually to large that calculating exact jacobian, even a 
> bounded one,
> is to expensive. But I would like to see how much is there 
> gain or lost of
> using exact jacobian in real example.

I was thinking especially of the 1D case. My feeling is that you might save 1,2 iterations, at the expense of twice as many function evaluations in each iteration. Typical iteration count is about 10+, probably a bit less in situations where newton actually works. This clearly gets *much* worse in the multidimensional case.

I am also thinking of dropping the extra args for the function call. At times in the past, I would have killed for this in some circumstances, but if really needed in python one could do something like

class myf :

	def __init__(self,arg1,arg2):
		self.arg1 = arg1

	def f(self,x) :
		return value depending on x and self.arg1,...


or even

def f(x) :
	global arg1,...
	return value depending on x and arg1,...

or some such.

The fact that f might be a method instead of a plain old function needs to be detected, but this is needed anyway. In Fortran-77, if I recall, some sort of common was needed to achieve this sort of thing easily. Comments? Is this a good idea or a total kludge.


> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

More information about the Scipy-dev mailing list