Re: [Numpy-discussion] function name as parameter
> I'm trying to write an implementation of the amoeba function from > numerical recipes and need to be able to pass a function name and > parameter list to be called from within the amoeba function. Simply > passing the name as a string doesn't work since python doesn't know it > is a function and throws a typeerror. Is there something similar to > IDL's 'call_function' routine in python/numpy or a pythonic/numpy > means > of passing function names? Just pass the function itself! For example: def foo(): print 6 def call_function_repeatedly(func, count): for i in range(count): func() call_function_repeatedly(foo, 2) # calls foo twice bar = foo bar() # still calls foo... we've just assigned the function to a different name In python, functions (and classes, and everything else) are first- class objects and can be assigned to variables, passed around, etc, etc, just as anything else. However, note that scipy.optimize.fmin implements the Nelder-Mead simplex algorithm, which is (I think) the same as the "amoeba" optimizer. Also you might be interested in the openopt package, which implements more optimizers a bit more consistently than scipy.optimize. Zach ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
If you really need to pass the function name :
In [3]: def my_func(x):
...: return 2*x
In [4]: def caller(fname,x):
...: return eval("%s(%f)"%(fname,x))
In [5]: caller("my_func",2)
Out[5]: 4.0
On 10/20/2010 03:46 PM, Zachary Pincus wrote:
>> I'm trying to write an implementation of the amoeba function from
>> numerical recipes and need to be able to pass a function name and
>> parameter list to be called from within the amoeba function. Simply
>> passing the name as a string doesn't work since python doesn't know it
>> is a function and throws a typeerror. Is there something similar to
>> IDL's 'call_function' routine in python/numpy or a pythonic/numpy
>> means
>> of passing function names?
>>
> Just pass the function itself! For example:
>
> def foo():
> print 6
>
> def call_function_repeatedly(func, count):
> for i in range(count):
> func()
>
> call_function_repeatedly(foo, 2) # calls foo twice
>
> bar = foo
> bar() # still calls foo... we've just assigned the function to a
> different name
>
>
> In python, functions (and classes, and everything else) are first-
> class objects and can be assigned to variables, passed around, etc,
> etc, just as anything else.
>
> However, note that scipy.optimize.fmin implements the Nelder-Mead
> simplex algorithm, which is (I think) the same as the "amoeba"
> optimizer. Also you might be interested in the openopt package, which
> implements more optimizers a bit more consistently than scipy.optimize.
>
> Zach
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, Oct 20, 2010 at 9:46 AM, Zachary Pincus wrote:
>> I'm trying to write an implementation of the amoeba function from
>> numerical recipes and need to be able to pass a function name and
>> parameter list to be called from within the amoeba function. Simply
>> passing the name as a string doesn't work since python doesn't know it
>> is a function and throws a typeerror. Is there something similar to
>> IDL's 'call_function' routine in python/numpy or a pythonic/numpy
>> means
>> of passing function names?
>
> Just pass the function itself! For example:
>
> def foo():
> print 6
>
> def call_function_repeatedly(func, count):
> for i in range(count):
> func()
>
> call_function_repeatedly(foo, 2) # calls foo twice
>
> bar = foo
> bar() # still calls foo... we've just assigned the function to a
> different name
>
>
> In python, functions (and classes, and everything else) are first-
> class objects and can be assigned to variables, passed around, etc,
> etc, just as anything else.
This is the best way, but if you want to pass the function name as
string, then you need to get the function with getattr
for example, scipy has code like this
def func(distname, args):
distfn = getattr(scipy.stats, distname)
distfn.rvs(args)
func('norm')
Josef
>
> However, note that scipy.optimize.fmin implements the Nelder-Mead
> simplex algorithm, which is (I think) the same as the "amoeba"
> optimizer. Also you might be interested in the openopt package, which
> implements more optimizers a bit more consistently than scipy.optimize.
>
> Zach
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, 2010-10-20 at 09:46 -0400, Zachary Pincus wrote: > > I'm trying to write an implementation of the amoeba function from > > numerical recipes and need to be able to pass a function name and > > parameter list to be called from within the amoeba function. Simply > > passing the name as a string doesn't work since python doesn't know it > > is a function and throws a typeerror. Is there something similar to > > IDL's 'call_function' routine in python/numpy or a pythonic/numpy > > means > > of passing function names? > > Just pass the function itself! For example: > > def foo(): >print 6 > > def call_function_repeatedly(func, count): >for i in range(count): > func() > > call_function_repeatedly(foo, 2) # calls foo twice > > bar = foo > bar() # still calls foo... we've just assigned the function to a > different name > This works fine. Too obvious to see, I guess. > > In python, functions (and classes, and everything else) are first- > class objects and can be assigned to variables, passed around, etc, > etc, just as anything else. > > However, note that scipy.optimize.fmin implements the Nelder-Mead > simplex algorithm, which is (I think) the same as the "amoeba" > optimizer. Also you might be interested in the openopt package, which > implements more optimizers a bit more consistently than scipy.optimize. I try this and compare performance. I had looked for an 'amoeba' function, but couldn't find anything by that name. I should have broadened my search a bit. ;-) > > Zach > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Thomas K. Gamble Research Technologist, System/Network Administrator Chemical Diagnostics and Engineering (C-CDE) Los Alamos National Laboratory MS-E543,p:505-665-4323 f:505-665-4267 There cannot be a crisis next week. My schedule is already full. Henry Kissinger ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote: > I'm trying to write an implementation of the amoeba function from > numerical recipes and need to be able to pass a function name and > parameter list to be called from within the amoeba function. 1. Have you checked whether this might already be in OpenOpt? 2. Here is a GAUSS version, that might (?) be easier to follow. http://www1.american.edu/academic.depts/cas/econ/gaussres/optimize/honore.src Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, 2010-10-20 at 13:18 -0400, Alan G Isaac wrote: > On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote: > > I'm trying to write an implementation of the amoeba function from > > numerical recipes and need to be able to pass a function name and > > parameter list to be called from within the amoeba function. > > 1. Have you checked whether this might already be in OpenOpt? > 2. Here is a GAUSS version, that might (?) be easier to follow. > http://www1.american.edu/academic.depts/cas/econ/gaussres/optimize/honore.src Yes, Zachary already pointed out a version in the scipy.optimize module. Thanks anyway for the reference. I tend to prefer evaluating multiple options rather than just taking the first one that seems to work. > > Alan Isaac > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Thomas K. Gamble Research Technologist, System/Network Administrator Chemical Diagnostics and Engineering (C-CDE) Los Alamos National Laboratory MS-E543,p:505-665-4323 f:505-665-4267 There cannot be a crisis next week. My schedule is already full. Henry Kissinger ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi
wrote:
> If you really need to pass the function name :
> In [3]: def my_func(x):
> ...: return 2*x
>
> In [4]: def caller(fname,x):
> ...: return eval("%s(%f)"%(fname,x))
>
> In [5]: caller("my_func",2)
> Out[5]: 4.0
The better way to do this is:
import inspect
def call_this(fname, x):
caller_frame = inspect.currentframe().f_back
f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname))
return f(x)
IMPORTANT USAGE NOTE: never do this :-)
-- Nathaniel
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
> On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi
> wrote:
>
>> If you really need to pass the function name :
>> In [3]: def my_func(x):
>> ...: return 2*x
>>
>> In [4]: def caller(fname,x):
>> ...: return eval("%s(%f)"%(fname,x))
>>
>> In [5]: caller("my_func",2)
>> Out[5]: 4.0
>>
> The better way to do this is:
>
> import inspect
> def call_this(fname, x):
>caller_frame = inspect.currentframe().f_back
>f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname))
>return f(x)
>
>
thanks for this probably safer way to do this (I guess safer, as I know
nothing about inspect module, but can imagine the value of being
explicit as to frames and namespaces)
> IMPORTANT USAGE NOTE: never do this :-)
>
What would you recommand? I do encounter situations where I need
instantiation based on the name of the thing to instantiate, typically
passed as an argument by the client code/user.
thanks in advance,
Johann
> -- Nathaniel
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi wrote: > On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >> IMPORTANT USAGE NOTE: never do this :-) >> > What would you recommand? I do encounter situations where I need > instantiation based on the name of the thing to instantiate, typically > passed as an argument by the client code/user. Example? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, Oct 20, 2010 at 1:58 PM, Johann Cohen-Tanugi wrote: > On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >> The better way to do this is: >> >> import inspect >> def call_this(fname, x): >> caller_frame = inspect.currentframe().f_back >> f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname)) >> return f(x) > > thanks for this probably safer way to do this (I guess safer, as I know > nothing about inspect module, but can imagine the value of being explicit as > to frames and namespaces) Right, there are two big advantages: (1) it looks up the name in the *caller*'s namespace, so it works even if the function is called from another module, (2) you don't have to rely on 'x' going float->string->back to float. (Which probably doesn't make much difference if you just have a single float argument, but for anything more complicated you can avoid a lot of hassle.) >> IMPORTANT USAGE NOTE: never do this :-) > > What would you recommand? I do encounter situations where I need > instantiation based on the name of the thing to instantiate, typically > passed as an argument by the client code/user. > thanks in advance, Really, the recommendation is to define your API differently, so that people pass in actual objects (or whatever makes sense) instead of strings. But if you need to do this ugly thing for some reason (I've only needed it once, in a *very* exotic situation way outside what any normal scientific programmer would run into), then 'inspect' is probably the best way to accomplish it. -- Nathaniel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On 10/20/2010 11:10 PM, Robert Kern wrote:
> On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi
> wrote:
>
>> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>>
>
>>> IMPORTANT USAGE NOTE: never do this :-)
>>>
>>>
>> What would you recommand? I do encounter situations where I need
>> instantiation based on the name of the thing to instantiate, typically
>> passed as an argument by the client code/user.
>>
> Example?
>
>
Hi Robert,
so in a big data analysis framework, that is essentially written in C++,
exposed to python with SWIG, plus dedicated python modules, the user
performs an analysis choosing some given modules by name,as in :
myOpt="foo"
my_analyse.perform(use_optimizer=myOpt)
The attribute use_optimizer is then checked to perform the right
calls/instantiations of python but also C++ objects. and the actual
crunching number is in the C++ part.
But then I realize that I need to tweak this optimizer's state, and the
optimizer object is accessible from a library pyOpt that has been
swigified from a C++ library.
Then I access the object by calling optObject =
eval("pyOpt.%s(some_args)"%myOpt)
where myOpt would be "foo" in this particular analysis. This is because
what the attribute use_optimizer expects is also the object name in the
library, of course.
It goes without saying that I could do :
if myOpt=="foo":
optObject=pyOpt.foo(some_args)
else:
and if you guys tell me it is way safer, I will do that instead of the
use of eval that I liked because of the compactness.
As to Nathaniel's last point : yes of course the type changing of 'x' in
my code would be unacceptable if x becomes complicated enough. This was
not meant to be used in *any* situation.
cheers,
Johann
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
> Hi Robert,
> so in a big data analysis framework, that is essentially written in C
> ++,
> exposed to python with SWIG, plus dedicated python modules, the user
> performs an analysis choosing some given modules by name,as in :
> myOpt="foo"
> my_analyse.perform(use_optimizer=myOpt)
>
> The attribute use_optimizer is then checked to perform the right
> calls/instantiations of python but also C++ objects. and the
> actual
> crunching number is in the C++ part.
> But then I realize that I need to tweak this optimizer's state, and
> the
> optimizer object is accessible from a library pyOpt that has been
> swigified from a C++ library.
> Then I access the object by calling optObject =
> eval("pyOpt.%s(some_args)"%myOpt)
> where myOpt would be "foo" in this particular analysis. This is
> because
> what the attribute use_optimizer expects is also the object name in
> the
> library, of course.
> It goes without saying that I could do :
> if myOpt=="foo":
> optObject=pyOpt.foo(some_args)
> else:
>
> and if you guys tell me it is way safer, I will do that instead of the
> use of eval that I liked because of the compactness.
Well, optObject=getattr(pyOpt, myOpt) is a bit nicer and marginally
more likely to return sane error messages than optObject=eval("pyOpt.
%s"%myOpt). Then you could do result=optObject(some_args)...
But why not have the user just pass in the relevant optObject from the
pyOpt namespace (or some restricted namespace that just has the
relevant functions exposed)? E.g.
my_analysis.perform(optimizer=pyOpt.Amoeba)
rather than
my_analysis.perform(optimizer='Amoeba')
This lets users do introspection on the pyOpt namespace to see what
functions they can choose from, which is rather friendlier in an
interactive environment.
Zach
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On Wed, Oct 20, 2010 at 16:49, Zachary Pincus wrote: > But why not have the user just pass in the relevant optObject from the > pyOpt namespace (or some restricted namespace that just has the > relevant functions exposed)? E.g. > my_analysis.perform(optimizer=pyOpt.Amoeba) > rather than > my_analysis.perform(optimizer='Amoeba') +11ty-billion > This lets users do introspection on the pyOpt namespace to see what > functions they can choose from, which is rather friendlier in an > interactive environment. Or implement their own without having to modify pyOpt. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
Johann Cohen-Tanugi wrote:
> On 10/20/2010 11:10 PM, Robert Kern wrote:
>
>> On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi
>> wrote:
>>
>>
>>> On 10/20/2010 10:35 PM, Nathaniel Smith wrote:
>>>
>>>
>>
>>
IMPORTANT USAGE NOTE: never do this :-)
>>> What would you recommand? I do encounter situations where I need
>>> instantiation based on the name of the thing to instantiate, typically
>>> passed as an argument by the client code/user.
>>>
>>>
>> Example?
>>
>>
>>
> Hi Robert,
> so in a big data analysis framework, that is essentially written in C++,
> exposed to python with SWIG, plus dedicated python modules, the user
> performs an analysis choosing some given modules by name,as in :
> myOpt="foo"
> my_analyse.perform(use_optimizer=myOpt)
>
> The attribute use_optimizer is then checked to perform the right
> calls/instantiations of python but also C++ objects. and the actual
> crunching number is in the C++ part.
> But then I realize that I need to tweak this optimizer's state, and the
> optimizer object is accessible from a library pyOpt that has been
> swigified from a C++ library.
> Then I access the object by calling optObject =
> eval("pyOpt.%s(some_args)"%myOpt)
> where myOpt would be "foo" in this particular analysis. This is because
> what the attribute use_optimizer expects is also the object name in the
> library, of course.
> It goes without saying that I could do :
> if myOpt=="foo":
> optObject=pyOpt.foo(some_args)
> else:
>
> and if you guys tell me it is way safer, I will do that instead of the
> use of eval that I liked because of the compactness.
>
In this case getattr fits... in general, in cases where one could do
if action == 'a':
a()
elif action == 'b':
b()
the nice (proper?) way of doing it is usually to populate a dictionary:
actions['a'] = a
actions['b'] = b
# automatically populate etc...
actions[action]()
And on the subject of passing strings around and eval-ing them:
http://cache.gawkerassets.com/assets/images/4/2010/03/for_traffic_cameras.jpg
Dag Sverre
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] function name as parameter
On 10/20/2010 11:49 PM, Zachary Pincus wrote:
>> Hi Robert,
>> so in a big data analysis framework, that is essentially written in C
>> ++,
>> exposed to python with SWIG, plus dedicated python modules, the user
>> performs an analysis choosing some given modules by name,as in :
>> myOpt="foo"
>> my_analyse.perform(use_optimizer=myOpt)
>>
>> The attribute use_optimizer is then checked to perform the right
>> calls/instantiations of python but also C++ objects. and the
>> actual
>> crunching number is in the C++ part.
>> But then I realize that I need to tweak this optimizer's state, and
>> the
>> optimizer object is accessible from a library pyOpt that has been
>> swigified from a C++ library.
>> Then I access the object by calling optObject =
>> eval("pyOpt.%s(some_args)"%myOpt)
>> where myOpt would be "foo" in this particular analysis. This is
>> because
>> what the attribute use_optimizer expects is also the object name in
>> the
>> library, of course.
>> It goes without saying that I could do :
>> if myOpt=="foo":
>> optObject=pyOpt.foo(some_args)
>> else:
>>
>> and if you guys tell me it is way safer, I will do that instead of the
>> use of eval that I liked because of the compactness.
>>
> Well, optObject=getattr(pyOpt, myOpt) is a bit nicer and marginally
> more likely to return sane error messages than optObject=eval("pyOpt.
> %s"%myOpt). Then you could do result=optObject(some_args)...
>
>
ok I definitely like that better than eval.
> But why not have the user just pass in the relevant optObject from the
> pyOpt namespace (or some restricted namespace that just has the
> relevant functions exposed)? E.g.
> my_analysis.perform(optimizer=pyOpt.Amoeba)
> rather than
> my_analysis.perform(optimizer='Amoeba')
>
Well, that means that the user now needs to know about the underlying
C++ library, etc
Just requiring from the user that he knows the *name* of the optimizer
was the primary driver.
But I understand that it easily drives to a dead-end.
my_analysis.perform(optimizer=pyOpt.Amoeba)
is definitely allowed in the code as well, and that is what I do after I
have fiddle with the optimizer object.
Thanks to all for the tips and advices!
Johann
> This lets users do introspection on the pyOpt namespace to see what
> functions they can choose from, which is rather friendlier in an
> interactive environment.
>
> Zach
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
