[Numpy-discussion] Writing new ufuncs
Mon May 12 01:03:59 CDT 2008
On Mon, May 12, 2008 at 12:37 AM, Anne Archibald
> 2008/5/11 Robert Kern <email@example.com>:
>> Perhaps, but ufuncs only allow 0 or 1 for this value, currently.
> That's a shame, minus infinity is the identity for maximum too.
>> Also, I was wrong about using PyUFunc_ff_f. Instead, use PyUFunc_ff_f_As_dd_d.
> Hmm. Well, I tried implementing logsum(), and it turns out neither
> PyUFunc_dd_d nor any of the other functions - mostly flagged as being
> part of the ufunc API and described in the automatically-generated
> ufunc_api.txt - are exported. All are static and not described in any
> header I could find. That said, I know scipy defines its own ufuncs,
> so it must either reimplement these or have some way I hadn't thought
> of to get at them.
They are not exported as symbols. They are "exported" to other
extension modules by #defining them to an element in an array just
like the rest of the numpy C API. import_ufunc() sets up all of those
#defines. They are automatically generated into the file
> I've attached a patch to add the ufunc logsum to numpy. It's a bit
> nasty for several reasons:
> * I wasn't sure where to put it, so I put it in _compiled_base.c in
> numpy/lib/src. I was very hesitant to touch umathmodule.c.src with its
> sui generis macro language.
The place to add it would be in code_generators/generate_umath.py,
which generates __umath_generated.c.
> * I'm not sure what to do about log1p - it seems to be available in
> spite of HAVE_LOG1P not being defined. In any case if it doesn't exist
> it seems crazy to implement it again here.
Then maybe our test for HAVE_LOG1P is not correct. I don't think we
can rely on its omnipresence, though.
> * since PyUFunc_dd_d does not seem to be exported, I just cut-n-pasted
> its code here. Obviously not a solution, but what are extension
> writers supposed to do?
> Do we want a ufunc version of logsum() in numpy? I got the impression
> that in spite of some people's doubts as to its utility there was a
> strong contingent of users who do want it.
Well, many of us were simply contending Chuck's contention that one
shouldn't need the log representation. I would probably toss it into
> This plus a logdot() would
> cover most of the operations one might want to do on numbers in log
> representation. (Maybe subtraction?). It could be written in pure
> python, for the most part, and reduce() would save a few exps and logs
> at the cost of a temporary, but accumulate() remains a challenge. (I
> don't expect many people feel the need for reduceat()).
> P.S. it was surprisingly difficult to persuade numpy to find my tests.
> I suppose that's what the proposed transition to nose is for? -A
"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
More information about the Numpy-discussion