>>>>> "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
|
