On Mon, May 12, 2008 at 12:37 AM, Anne Archibald <[EMAIL PROTECTED]> wrote: > 2008/5/11 Robert Kern <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
