[Numpy-discussion] Ufuncs and flexible types, CAPI
Tue Jan 10 12:26:17 CST 2012
Thanks for the reply.
I hoped somebody will prove me wrong on ufuncs' limitation: no flexible
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
(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.
On Tue, Jan 10, 2012 at 10:29 AM, Samuel John <email@example.com> 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 :-)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion