[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