[Numpy-discussion] Current ufunc signatures for review

Travis E. Oliphant oliphant@enthought....
Tue May 27 14:53:59 CDT 2008


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

> 4) IMHO, absolute('?') should return 'b'

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

I didn't see anything of alarm in the list of signatures that you 
provided.   If you have something of concern, please pick it out.

Thanks for the close-up examination of the behavior.

-Travis


>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>   



More information about the Numpy-discussion mailing list