[Numpy-discussion] numarray: Two edge case buglets for clip
jmiller at stsci.edu
Fri Jan 6 09:24:10 CST 2006
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(, 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
> # 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(, 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?
More information about the Numpy-discussion