Re: [Numpy-discussion] Ufuncs and flexible types, CAPI
[sorry for duplicate - I used the wrong mail address] I am afraid, I didn't quite get the question. What is the scenario? What is the benefit that would weight out the performance hit of checking whether there is a callback or not. This has to be evaluated quite a lot. Oh well ... and 1.3.0 is pretty old :-) cheers, Samuel On 31.12.2011, at 07:48, Val Kalatsky wrote: Hi folks, First post, may not follow the standards, please bear with me. Need to define a ufunc that takes care of various type. Fixed - no problem, userdef - no problem, flexible - problem. It appears that the standard ufunc loop does not provide means to deliver the size of variable size items. Questions and suggestions: 1) Please no laughing: I have to code for NumPy 1.3.0. Perhaps this issue has been resolved, then the discussion becomes moot. If so please direct me to the right link. 2) A reasonable approach here would be to use callbacks and to give the user (read programmer) a chance to intervene at least twice: OnInit and OnFail (OnFinish may not be unreasonable as well). OnInit: before starting the type resolution the user is given a chance to do something (e.g. check for that pesky type and take control then return a flag indicating a stop) before the resolution starts OnFail: the resolution took place and did not succeed, the user is given a chance to fix it. In most of the case these callbacks are NULLs. I could patch numpy with a generic method that does it, but it's a shame not to use the good ufunc machine. Thanks for tips and suggestions. Val Kalatsky ___ 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] Ufuncs and flexible types, CAPI
Hi Samuel, Thanks for the reply. I hoped somebody will prove me wrong on ufuncs' limitation: no flexible type support. Also wanted to bring up a discussion on changing ufunc API. I think adding another parameter that delivers pointers to arrays to the loops would not lead to any undesirable consequences. Yep, 1.3.0 is old, but 1.7 has same loop prototype (with some minor cosmetic change): (char **args, intp *dimensions, intp *steps, void *func) - (char **args, intp *dimensions, intp *steps, void *NPY_UNUSED(func)) it probably has not change from the conception. Thanks Val On Tue, Jan 10, 2012 at 10:29 AM, Samuel John sc...@samueljohn.de wrote: [sorry for duplicate - I used the wrong mail address] I am afraid, I didn't quite get the question. What is the scenario? What is the benefit that would weight out the performance hit of checking whether there is a callback or not. This has to be evaluated quite a lot. Oh well ... and 1.3.0 is pretty old :-) cheers, Samuel On 31.12.2011, at 07:48, Val Kalatsky wrote: Hi folks, First post, may not follow the standards, please bear with me. Need to define a ufunc that takes care of various type. Fixed - no problem, userdef - no problem, flexible - problem. It appears that the standard ufunc loop does not provide means to deliver the size of variable size items. Questions and suggestions: 1) Please no laughing: I have to code for NumPy 1.3.0. Perhaps this issue has been resolved, then the discussion becomes moot. If so please direct me to the right link. 2) A reasonable approach here would be to use callbacks and to give the user (read programmer) a chance to intervene at least twice: OnInit and OnFail (OnFinish may not be unreasonable as well). OnInit: before starting the type resolution the user is given a chance to do something (e.g. check for that pesky type and take control then return a flag indicating a stop) before the resolution starts OnFail: the resolution took place and did not succeed, the user is given a chance to fix it. In most of the case these callbacks are NULLs. I could patch numpy with a generic method that does it, but it's a shame not to use the good ufunc machine. Thanks for tips and suggestions. Val Kalatsky ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Ufuncs and flexible types, CAPI
Hi folks, First post, may not follow the standards, please bear with me. Need to define a ufunc that takes care of various type. Fixed - no problem, userdef - no problem, flexible - problem. It appears that the standard ufunc loop does not provide means to deliver the size of variable size items. Questions and suggestions: 1) Please no laughing: I have to code for NumPy 1.3.0. Perhaps this issue has been resolved, then the discussion becomes moot. If so please direct me to the right link. 2) A reasonable approach here would be to use callbacks and to give the user (read programmer) a chance to intervene at least twice: OnInit and OnFail (OnFinish may not be unreasonable as well). OnInit: before starting the type resolution the user is given a chance to do something (e.g. check for that pesky type and take control then return a flag indicating a stop) before the resolution starts OnFail: the resolution took place and did not succeed, the user is given a chance to fix it. In most of the case these callbacks are NULLs. I could patch numpy with a generic method that does it, but it's a shame not to use the good ufunc machine. Thanks for tips and suggestions. Val Kalatsky ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
