Re: [Numpy-discussion] int and float ufunc?

[Andrew P. L. <bs...@ma...>]

On Mon, 7 Oct 2002, Travis Oliphant wrote:

> > Could someone explain the reason why int() and float() don't work as
> > ufuncs?  Is it just that someone needs to write the code, or is there some
> > subtlety at work that I am missing?
>
> What would you have them do?  Their current definition works for returning
> suitable arrays as integers and floats respectively, just as the Python
> documentation says these two functions should.

Okay, now I'm really confused ...

>>> import Numeric
>>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
>>> a
array([ 1.5,  2.5,  3.5])
>>> int(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Only rank-0 arrays can be converted to Python scalars.

I guess I'm really dense, but how does that result constitute a definition
that "works"?  Has this behavior changed recently such that I should
update my version of Numeric?  If so, that would be a wonderful solution
to my problem (explained below).

> It would be an easy thing to map int() to oldarray.astype(Int) and so
> forth but is this a good policy.  I submit it is not.

I could be persuaded either way.  I was simply wondering what the
arguments were.

My usage is in converting vectors of data before passing them to the
screen for display.  The conversion function is a bunch of ufuncs and then
the resulting vector needs to get converted to int before being passed to
X.  The same code works for Python floats, scalars, or Numeric arrays with
the exception of the int function.

If the problem was simply a lack of someone to write the code, I thought I
might do it.  I thought it might be a little faster than me writing array
versions of all of my conversion functions, although I haven't looked at
the complexity of the Numeric code.  So, I could be completely wrong about
that.

If the traceback is "designed" behavior, I guess I'll just have to suck it
up and write array versions of my functions.

Thanks,
-a