numarray bug: dot product between 2x2 and 3x2x3 on Mac different from PC
Hi! This is what I got:
import numarray as na na.__version__ '1.4.0' bbb=na.zeros((2,3,3), naFloat32) bbb[0,:,:]=1 bbb[1,:,:]=2 ccc=na.transpose(bbb,(1,0,2)) d=na.array([[1,0],[0,1]]) na.dot(d,ccc) [[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]] This is on a PC (Windows or Linux): But if you do the same thing on Mac, the result will be: [[[ 1. 1. 1.] [ 2. 2. 2.] [ 1. 1. 1.]] [[ 2. 2. 2.] [ 1. 1. 1.] [ 2. 2. 2.]]] Can someone confirm this ? (the new numpy on windows also gives the first result) Thanks, Sebastian Haase
Sebastian Haase wrote:
Hi! This is what I got:
Can someone confirm this ?
This is what I get on Linux (ix86, Fedora core4, python 2.4.3)
import numarray as na na.__version__ '1.5.0'
bbb=na.zeros((2,3,3), na.Float32) bbb[0,:,:]=1 bbb[1,:,:]=2 bbb array([[[ 1., 1., 1.], [ 1., 1., 1.], [ 1., 1., 1.]],
[[ 2., 2., 2.], [ 2., 2., 2.], [ 2., 2., 2.]]], type=Float32)
ccc=na.transpose(bbb,(1,0,2)) ccc array([[[ 1., 1., 1.], [ 2., 2., 2.]],
[[ 1., 1., 1.], [ 2., 2., 2.]], [[ 1., 1., 1.], [ 2., 2., 2.]]], type=Float32)
d=na.array([[1,0],[0,1]]) d array([[1, 0], [0, 1]]) na.dot(d,ccc) array([[[ 1., 1., 1.], [ 2., 2., 2.], [ 1., 1., 1.]],
[[ 2., 2., 2.], [ 1., 1., 1.], [ 2., 2., 2.]]], type=Float32)
-- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
And on my Mac: OS-X 10.4.*, PPC, universal python 2.4.3:
import numarray as na na.__version__ '1.5.1' bbb=na.zeros((2,3,3), na.Float32) bbb[0,:,:]=1 bbb[1,:,:]=2 ccc=na.transpose(bbb,(1,0,2)) d=na.array([[1,0],[0,1]]) na.dot(d,ccc) array([[[ 1., 1., 1.], [ 2., 2., 2.], [ 1., 1., 1.]],
[[ 2., 2., 2.], [ 1., 1., 1.], [ 2., 2., 2.]]], type=Float32) -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Thanks Chris, If this got fixed towards numarray version 1.5.1 it looks like it is now on both Linux and Mac different(!) from the numpy result I got on Window !! On Linux I get:
import numpy as N N.__version__ '0.9.9.2823' bbb=N.zeros((2,3,3), N.float32) bbb[0,:,:]=1 bbb[1,:,:]=2 bbb [[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
ccc=N.transpose(bbb,(1,0,2)) d=N.array([[1,0],[0,1]]) d [[1 0] [0 1]] N.dot(d,ccc) Traceback (most recent call last): File "<input>", line 1, in ? TypeError: array cannot be safely cast to required type dd=d.astype(N.float32) N.dot(dd,ccc) [[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
The TypeError looks like a numpy bug ! Thanks, Sebastian Haase On Monday 17 July 2006 11:29, Christopher Barker wrote:
And on my Mac:
OS-X 10.4.*, PPC, universal python 2.4.3:
import numarray as na na.__version__
'1.5.1'
bbb=na.zeros((2,3,3), na.Float32) bbb[0,:,:]=1 bbb[1,:,:]=2 ccc=na.transpose(bbb,(1,0,2)) d=na.array([[1,0],[0,1]]) na.dot(d,ccc)
array([[[ 1., 1., 1.], [ 2., 2., 2.], [ 1., 1., 1.]],
[[ 2., 2., 2.], [ 1., 1., 1.], [ 2., 2., 2.]]], type=Float32)
Sebastian Haase wrote:
Traceback (most recent call last): File "<input>", line 1, in ? TypeError: array cannot be safely cast to required type
dd=d.astype(N.float32) N.dot(dd,ccc)
[[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
The TypeError looks like a numpy bug !
I don't see why this is a bug. You are trying to coerce a 32-bit integer to a 32-bit float. That is going to lose precision and so you get the error indicated. -Travis
On Monday 17 July 2006 12:10, Travis Oliphant wrote:
Sebastian Haase wrote:
Traceback (most recent call last): File "<input>", line 1, in ? TypeError: array cannot be safely cast to required type
dd=d.astype(N.float32) N.dot(dd,ccc)
[[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
The TypeError looks like a numpy bug !
I don't see why this is a bug. You are trying to coerce a 32-bit integer to a 32-bit float. That is going to lose precision and so you get the error indicated.
-Travis In numarray I do not get an error. Would the error go away if I had 64 bit float !? It seems though that having ones and twos in an int array should fit just fine into a float32 array !?
- Sebastian Haase
Sebastian Haase wrote:
On Monday 17 July 2006 12:10, Travis Oliphant wrote:
Sebastian Haase wrote:
Traceback (most recent call last): File "<input>", line 1, in ? TypeError: array cannot be safely cast to required type
dd=d.astype(N.float32) N.dot(dd,ccc)
[[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
The TypeError looks like a numpy bug !
I don't see why this is a bug. You are trying to coerce a 32-bit integer to a 32-bit float. That is going to lose precision and so you get the error indicated.
-Travis
In numarray I do not get an error. Would the error go away if I had 64 bit float !? It seems though that having ones and twos in an int array should fit just fine into a float32 array !?
This could be considered a bug in numarray. It's force-casting the result. That isn't the normal behavior of mixed-type functions. Also, the policy on type-casting is not to search the array to see if it's possible to do the conversion on every element (that would be slow on large arrays). The policy is to base the decision only on the data-types themselves (i.e. whether it's *possible* to lose precision*). -Travis *There is one exception to this policy in NumPy: 64-bit integers are allowed to be cast to 64-bit doubles --- other-wise on you would get a lot of non-standard long-doubles showing up on 64-bit systems. This policy was decided after discussion last year.
On Monday 17 July 2006 12:38, Travis Oliphant wrote:
Sebastian Haase wrote:
On Monday 17 July 2006 12:10, Travis Oliphant wrote:
Sebastian Haase wrote:
Traceback (most recent call last): File "<input>", line 1, in ? TypeError: array cannot be safely cast to required type
> dd=d.astype(N.float32) > N.dot(dd,ccc)
[[[ 1. 1. 1.] [ 1. 1. 1.] [ 1. 1. 1.]]
[[ 2. 2. 2.] [ 2. 2. 2.] [ 2. 2. 2.]]]
The TypeError looks like a numpy bug !
I don't see why this is a bug. You are trying to coerce a 32-bit integer to a 32-bit float. That is going to lose precision and so you get the error indicated.
-Travis
In numarray I do not get an error. Would the error go away if I had 64 bit float !? It seems though that having ones and twos in an int array should fit just fine into a float32 array !?
This could be considered a bug in numarray. It's force-casting the result. That isn't the normal behavior of mixed-type functions.
Also, the policy on type-casting is not to search the array to see if it's possible to do the conversion on every element (that would be slow on large arrays). The policy is to base the decision only on the data-types themselves (i.e. whether it's *possible* to lose precision*).
-Travis
*There is one exception to this policy in NumPy: 64-bit integers are allowed to be cast to 64-bit doubles --- other-wise on you would get a lot of non-standard long-doubles showing up on 64-bit systems. This policy was decided after discussion last year.
OK - understood. Combining int32 with float64 proves to be less cumbersome ... Any idea on my main question ? What is the dot product of a 2x2 and 3x2x3 supposed to look like ? Why are numarray and numpy giving different answers ?? Thanks, Sebastian Haase
Sebastian Haase wrote:
On Monday 17 July 2006 12:38, Travis Oliphant wrote:
Any idea on my main question ? What is the dot product of a 2x2 and 3x2x3 supposed to look like ? Why are numarray and numpy giving different answers ??
I'm pretty sure the dot-product in Numeric (and I guess numarray too) was broken for larger than 2-dimensions. This was fixed several months ago in NumPy. NumPy dot-product gives the following result a.shape is (I,L) b.shape is (J,L,K) Then c=dot(a,b) will have c.shape = (I,J,K) with c[i,j,k] = sum(a[i,:]*b[j,:,k]) I'm not even sure what Numeric is computing in this case. -Travis
Sebastian Haase wrote:
OK - understood. Combining int32 with float64 proves to be less cumbersome ...
Why are numarray and numpy giving different answers ?
I have a little insight as to what is going on here but no fix. numarray has two versions of dot(): 1. The original dot() is standalone, easy to install, and basically works. This dot() does however have the type coercion wart where Int32 dotted with Float32 silently loses precision. 2. A more optimized dot(), ported from Numeric, depends on an external BLAS. This makes it faster but also generally harder to install. This optimized dot() has the higher dimensional array bug you discovered. For arrays of rank > 2, it's totally broken. Since Mac OS-X has a standard BLAS, it uses the optimized dot() by default and exposes the bug. The optimized dot() is easy to turn off in cfg_packages.py by commenting out the lines: # if os.path.exists('/System/Library/Frameworks/vecLib.framework'): # USE_LAPACK = True Since numarray is being phased out and neither issue is a serious problem for STScI, we're not planning to fix them. If it's causing someone major hardship let us know and we'll reconsider. Todd
participants (4)
-
Christopher Barker -
Sebastian Haase -
Todd Miller -
Travis Oliphant