[Numpy-discussion] Current ufunc signatures for review
Charles R Harris
Tue May 27 15:26:53 CDT 2008
On Tue, May 27, 2008 at 1:53 PM, Travis E. Oliphant <firstname.lastname@example.org>
> Charles R Harris wrote:
> > Hi All,
> > Here is the current behavior of the ufuncs and some comments. They
> > don't yet cover mixed types for binary functions,
> > but when they do we will see things like:
> > In : power(True,10)
> > Out:
> > array([ 0.5822807 , 0.66568381, 0.11748811, 0.97047323, 0.60095205,
> > 0.81218886, 0.0167618 , 0.80544138, 0.59540082, 0.82414302])
> > Which looks suspect ;)
> I don't understand this. Like Robert, I don't get this output, and I'm
> not sure what the point being made is.
It came from MPL, which used to have its own versions of some things.
> > 1) Help strings on ufuncs don't work. This seems to be a problem with
> > the help function, as
> > printing the relevant __doc__ works fine. The docstrings are
> > currently defined in
> > code_generators/generate_umath.py and add_newdoc doesn't seem to
> > work for them.
> This has been known for a long time. It is the reason that I wrote
> numpy.info. I should push for the Python help to change, but I'm not
> sure what problems that might create.
I'm thinking that maybe we could make the numpy module overload the builtin
help function when it is imported.
> > 2) Complex divmod(), // and % are deprecated, should we make them
> > raise errors?
> Sometimes you have float data that is complex because of an intermediate
> calculation. I don't think we should cause these operations not to
> work on Numeric data just because Python deprecated them. I'm actually
> not sure why Python deprecated these functions.
> > 3) The current behavior of remainder for complex is bizarre. Nor does
> > it raise a deprecation warning.
> Please show what you mean:
> >>> x = array([5.0, 3.0],'D')
> >>> x
> array([ 5.+0.j, 3.+0.j])
> >>> x % 3
> __main__:1: DeprecationWarning: complex divmod(), // and % are deprecated
> array([(2+0j), 0j], dtype=object)
> I don't get why it should be deprecated.
Hey, I didn't put in the warning. Although it currently segfaults for some
values and I'm not sure what the definition should be for the complex case.
> > 4) IMHO, absolute('?') should return 'b'
It's an arithmetic operator, not boolean.
> > 5) Negative applied to '?' is equivalent to not. This gives me mixed
> > feelings; the same functionality
> > is covered by invert and logical_not.
> Yes, it is true. Do you have another suggestion as to what negative
> should do?
Been thinking about it.
> > 6) The fmod ufunc applied to complex returns AttributeError. Shouldn't
> > it be a TypeError?
> Maybe, but the error comes from
> complex-> promoted to object -> search for fmod method on Python object
> of complex type -> raise Attribute Error.
> Some special-case error re-mapping would have to be done to change it.
> > 7) Should degrees and radians work on complex? Hey, they work on
> > booleans and it's just scaling.
> Sure -- for the same reason that floor_divide (//) and remainder (%)
> should work on complex (I realize that right now, the default object
> implementation is called for such cases).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion