Hi Oscar,

Let me clear up my description of one point - I don’t want to pick on the third 
party software guys.

> The "right" solution is to change the interface of the third party function. 
> It is poorly designed and should not be inspecting those function attributes 
> or it should at least provide an option for you to provide that information 
> in a different way. Assuming it's open source you could try sending a patch. 
> In the mean time you could copy that code and modify it to suit your purposes.

The issue has to do with making a general polynomial function, not passing the 
args of a “simple” function.  If I define

def f(c_0,c_1):
    return chisq(c_0,c_1,x,y,dy)

there is no problem using this function, the variables are all passed correctly.

What I am trying to avoid is having to write a special case for each order of 
polynomial I want.  I tried the following

def poly(x,pars):
    val = 0.
    for i,ci in enumerate(pars):
        val += x**i * ci
    return val
def f_lambda(x,pars):
    return lambda x,*pars: poly(x,*pars)
x = np.array([1,2,3])
f = f_lambda(x,[-.5,2.])
f(x,[-.5,2.])
array([ 1.5,  3.5,  5.5])

f(x,[-.5,3.])
array([ 2.5,  5.5,  8.5])
etc. 

This function correctly gives me a polynomial of arbitrary order, but

f.func_code.co_varnames
('x', 'pars’)

so I can not pass this to the third party minimizer, as it does not know how to 
interpret ‘pars'.  You can probably see trying to replicate the lambda function 
method for an arbitrary polynomial is what naturally led to the string/exec 
option.


Thanks,

Andre

_______________________________________________
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Reply via email to