numpy-discussion

[Numpy-discussion] Possible bug in scalar * array

[Edward C. J. <edc...@er...>]

#! /usr/bin/env python

# Python 2.3.2, numarray 0.7
import numarray

def fun1(code, scale):
     arr1 = numarray.ones((4,4), code)
     arr2 = scale * arr1
     arr3 = numarray.ones((4,4), code)
     # Bug appears at second multiply.
     arr4 = scale * arr3

def fun2(code, scale):
     arr = numarray.ones((4,4), code)
     arr2 = scale * arr
     # Bug appears at second multiply.
     arr3 = scale * arr

# These calls fail when "scale" is too big for "code":

#   File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
653, in __rmul__
#    def __rmul__(self, operand): return ufunc.multiply(operand, self)
# ValueError: invalid shape tuple

#fun2('Int16', 100000)
fun2('UInt8' , -1)

Re: [Numpy-discussion] Possible bug in scalar * array

[Todd M. <jm...@st...>]

I confirmed this and logged it on Source Forge as numpy-Numarray
Bugs-826311 [Numpy-discussion] Possible bug in scalar * array.

I don't have a fix yet.

Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun1(code, scale):
>      arr1 = numarray.ones((4,4), code)
>      arr2 = scale * arr1
>      arr3 = numarray.ones((4,4), code)
>      # Bug appears at second multiply.
>      arr4 = scale * arr3
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Possible bug in scalar * array

[Todd M. <jm...@st...>]

I tracked down the problem to some (relatively) new overflow checking
code which detects the overflow of the scalar -1 as it is assigned to an
array pseudo buffer of type UInt8.  This error was mishandled, and hence
was transformed into an invalid shape tuple (you gotta smile :-)).  The
*2nd* call is where the exception shows up because of caching logic.

I talked this over with Perry and we concluded that it's probably a good
thing to trap the out of range scalar values before using them.  Thus,
we're proposing to fix the error handling,  but to make the calls in
question raise an overflow exception on the first call.  We are
interested in hearing other opinions however.  Comments?

Regards,
Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

Re: [Numpy-discussion] Possible bug in scalar * array

[Francesc A. <fa...@op...>]

A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?

You mean implementing range checking in numarray objects? In my opinion,
that would be a very nice feature, although I don't know how that would
affect the assignment performance.

-- 
Francesc Alted

Re: [Numpy-discussion] Possible bug in scalar * array

[Todd M. <jm...@st...>]

On Tue, 2003-10-21 at 03:53, Francesc Alted wrote:
> A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> > I talked this over with Perry and we concluded that it's probably a good
> > thing to trap the out of range scalar values before using them.  Thus,
> > we're proposing to fix the error handling,  but to make the calls in
> > question raise an overflow exception on the first call.  We are
> > interested in hearing other opinions however.  Comments?
> 
> You mean implementing range checking in numarray objects? In my opinion,
> that would be a very nice feature, although I don't know how that would
> affect the assignment performance.

I don't anticipate any impact on performance for the limited scope we
were proposing:  overflow checking for the scalar parameters of binary
ufuncs.  There are other areas where overflow checking could be employed
but won't be.  So, trying to create a more coherent picture,

Here is where we will check for overflows:

1. fromlist(), if you specify check_overflow=1.  
2. scalar parameters of binary ufuncs.  So 1+a will make sure "1" fits
in the array implied by a.type().
3. non-array-sequence parameters of binary ufuncs.  So add(a,[1,2,3])
ensures that [1,2,3] can be stored in an array of the type implied by
array a. 
4. The multiply ufunc.
5. a[<single_element_index>] = x  whenever a._check_overflow is 1.

Here is where we won't check for overflows:

1. array(), or fromlist() by default.
2. most binary ufuncs.  So a+b won't check, assuming a and b are both
arrays.
3. a[<block_of_elements_index>] = b, regardless of a._check_overflow.

Comments?  Anything grossly inconsistent here?

> -- 
> Francesc Alted
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576