[Numpy-discussion] Writing new ufuncs

Robert Kern robert.kern@gmail....
Mon May 12 01:03:59 CDT 2008


On Mon, May 12, 2008 at 12:37 AM, Anne Archibald
<peridot.faceted@gmail.com> wrote:
> 2008/5/11 Robert Kern <robert.kern@gmail.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
__ufunc_api.h.

> 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?

See above.

> 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
scipy.special, myself.

> 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()).
>
> Anne
>
> 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

Yes.

-- 
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


More information about the Numpy-discussion mailing list