Edward C. Jones wrote:

#! /usr/bin/env python

import numarray from numarray.numerictypes import *

# I have a PC with an AMD Athlon 64 3500+ processor. The operating # system is up-to-date Debian unstable Linux. I use the "i386" # distribution, not the "amd64" distribution. The "i386" distribution # works on both 32 and 64 bit machines.

def bug1(): # Here is an edge case. Should the following work or not:

arr = numarray.array([100], Int8) arrout = numarray.clip(arr, -1000, 1000)

I don't think it's a bug that clip() doesn't silently turn itself into a no-op when given out of range limits. If you want to submit a patch to make clip() smarter, we'll consider it, but you should probably be pouring your energy into newcore/numpy instead.

# The documentation doesn't quite give the answer:

# "The clip function creates an array with the same shape and # type as m, but where every entry in m that is less than m_min # is replaced by m_min, and every entry greater than m_max is # replaced by m_max. Entries within the range [m_min, m_max] are # left unchanged."

# In image processing, I can easily imagine a loop where # numarrays of various types are all clipped to [0, 255]. # Therefore I think that the "clip" above should return a copy of # arr.

def bug2(): # In this case, 2**63 _is_ representable as a UInt64. arr = numarray.array([100], UInt64) print arr.type(), arr arrout = numarray.clip(arr, 0, 2**63-1) print arr.type(), arrout arrout = numarray.clip(arr, 0, 2**63) print arrout

I agree that bug2 is a problem and logged this on Source Forge. Is bug2 impacting you or can you work around it? Regards, Todd