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? It took a bit of digging to go find the fact that what I wanted is newarray = oldarray.astype(MagicNewTypeCode) Thanks, -a
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. 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. -Travis O.
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
On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:
On Mon, 7 Oct 2002, Travis Oliphant wrote:
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"?
See ^^^ above. In this case, suitable arrays are rank-0 arrays. So, the definition works (see also 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.
According to int.__doc__, int(..) should *always* return a Python integer. But you are asking for an integer array as a result of int(array(..)); and that would be a contradiction with the Python definition for int(anyobj). Pearu
On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:
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 didn't mean to confuse you. I said "suitable" arrays. Returning a single Python integer from an array doesn't really make sense unless that array is 0-dimensional (rank-0). Now, one could argue that an array of length 1 could also be converted unambiguously, but that discussion has never taken place. Python uses the int() function to return a Python integer type whenever it is explicitly needed.
I could be persuaded either way. I was simply wondering what the arguments were.
The main argument is that int() should return a Python integer type representation of your object. There is no way to unambiguously return a Python integer object from a general array unless that array contains only one element. Currently the int() function only converts rank-0 arrays (which are Numeric scalars with array headers).
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.
I don't understand what the problem is. Why does X.astype() not work for you here? What do you mean "passed to X?" Is this in C, in Python? The int() function was never intended to work on general Numeric arrays. It could be made to (and would be a very simple job), but that discussion has never taken place. instead of int() why don't you use asarray(x).astype('l') for your code
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 you look in SciPy (www.scipy.org), we have defined a dictionary of cast functions for each of the types that works the way you apparently wanted int() to work. Using this command you would write scipy.cast[Numeric.Int](<your object>) I don't know what your functions are, but I doubt array versions would be that difficult to write. I guess I just always write array versions of my functions. Almost every routine I write starts with asarray(x) to convert inputs to array objects Good luck, -Travis O.
On Mon, 7 Oct 2002, Travis Oliphant wrote:
The main argument is that int() should return a Python integer type representation of your object. There is no way to unambiguously return a Python integer object from a general array unless that array contains only one element.
Okay.
I don't understand what the problem is. Why does X.astype() not work for you here?
I guess I wasn't clear here. It does. However, I have *lots* of these functions scattered around the code (inherited from someone else), so I will have to hunt them all down and change all the int(thingtoconvert) to thingtoconvert.astype('l'). Since there are good arguments for int behaving the way it does, I'll make the changes required to my code. No big deal, just lots of tedium. Thanks for taking the time to explain this, -a
On Mon, Oct 07, 2002 at 11:56:48AM -0700, Andrew P. Lentvorski wrote:
However, I have *lots* of these functions scattered around the code (inherited from someone else), so I will have to hunt them all down and change all the int(thingtoconvert) to thingtoconvert.astype('l').
How about defining a function like so: def int(object, **kwds): if type(object) is Numeric.ArrayType: return object.astype(Numeric.Integer) else: return __builtins__.int(object, **kwds) That should probably take care of all uses of int() in your code. -- Robert Kern Ruddock House President kern@caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
On Mon, 7 Oct 2002, Robert Kern wrote:
On Mon, Oct 07, 2002 at 11:56:48AM -0700, Andrew P. Lentvorski wrote:
However, I have *lots* of these functions scattered around the code (inherited from someone else), so I will have to hunt them all down and change all the int(thingtoconvert) to thingtoconvert.astype('l').
How about defining a function like so:
def int(object, **kwds): if type(object) is Numeric.ArrayType: return object.astype(Numeric.Integer) else: return __builtins__.int(object, **kwds)
That should probably take care of all uses of int() in your code.
I would rename this function to `aint' and still change all the int(x) to aint(x). When messing with Python built-ins, sooner or later you'll find a bullet in your leg ... Pearu
participants (4)
-
Andrew P. Lentvorski -
Pearu Peterson -
Robert Kern -
Travis Oliphant