[Numpy-discussion] Current ufunc signatures for review

[Charles R Harris]

On Tue, May 27, 2008 at 1:53 PM, Travis E. Oliphant <oliphant at enthought.com>
wrote:

> 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 [7]: power(True,10)
> > Out[7]:
> > 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'
>
> Reasons?


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

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080527/dbb0dc78/attachment.html>