On Tue, May 17, 2011 at 7:32 PM, Charles R Harris <[email protected] > wrote:
> > > On Tue, May 17, 2011 at 6:47 PM, Wieland Brendel > <[email protected]>wrote: > >> >> Hello, >> I am encountering a very strange behaviour of einsum on my machine. I >> tracked the problem down to the following test code: >> >> from numpy import * >> >> T = random.random((3,10,10)) >> W = random.random((3,10,7,275)) >> >> print all(einsum('ij...,j...->i...',T[0],W[0]) + >> einsum('ij...,j...->i...',T[1],W[1]) + einsum('ij...,j...->i...',T[2],W[2]) >> - einsum('pij,pjts->its',T,W)< 1e-10) >> print sum(abs(einsum('ij...,j...->i...',T[0],W[0]) + >> einsum('ij...,j...->i...',T[1],W[1]) + einsum('ij...,j...->i...',T[2],W[2]) >> - einsum('pij,pjts->its',T,W))) >> >> On my machine the equality is not fulfilled. However, this depends, >> strange enough, on the dimensions of W: if the last dimension e.g. is >> 500 instead of 275, things work again and the equality is fulfilled. >> >> > The equality being that the expression should be ~0? > > I see the problem when the last index is in the range 235 - 390. > > >> Are you encountering similar problems or is this just my >> machine/installation? >> >> > Out of curiosity, which machine/OS are you using? I'm on 64 bit fedora 14, > AMD 940. > > Using T = ones((2,8,8)) W = ones((2,8,8,i)) The problem occurs for i in the closed ranges 129..204 and 257..341. The starting points look suspicious but the end points not so much. I think something isn't getting reset to zero. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
