From: Raymond T. <to...@rt...> - 2002-07-26 20:42:31
|
>>>>> "Raymond" == Raymond Toy <to...@rt...> writes: >>>>> "Mike" == mak <ma...@ll...> writes: Mike> Ray, Mike> I may have spoken too soon. Yes, the SEGMENT violation is gone. However, Mike> I stumbled upon this. I define three distinct vectors *WS*, *WD*, and D. Mike> Then I compute the following Mike> (dot *ws* d): 5.771771444577276d0 Mike> (dot *wd* d): #C(0.0d0 -8.946814341083627d0) Mike> (/ (m:dot *wd* d) (m:dot *ws* d)): #C(1.0d0 0.0d0) Mike> ==> THIS SHOULD HAVE BEEN #C(0.0D0 -1.5500985142939754D0) <== Mike> Now what? I'm clueless on how to track this one down. Raymond> This is very, very weird. I'll look in to it. And actually, it's an I have a sneaking suspicion that this is a compiler bug where it thinks that the temp variable used to hold the result of zdotc/zdotu is never modified. And since that temp variable is initialized to the constant #c(0d0 0d0), it leaves it in a fixed place. Thus, the result of zdotc is recycled over and over. We don't see it if you save the intermediate result because a copy is made. In any case, I think the following solves the immediate problem: (defmethod dot ((x complex-matrix) (y complex-matrix) &optional (conjugate-p t)) (let* ((nxm (number-of-elements x)) (store-x (store x)) (store-y (store y)) (dot (if conjugate-p (zdotc nxm store-x 1 store-y 1) (zdotu nxm store-x 1 store-y 1)))) (if (zerop (imagpart dot)) (realpart dot) (complex (realpart dot) (imagpart dot))))) I think this need to be fixed in ffi-cmu.lisp in some way. There's no telling what other bugs will be found because of this, if I'm right. Ray |