Menu
▾
▴
matlisp-devel
|
From: <ma...@ll...> - 2002-07-26 15:06:39
|
Ray,
I may have spoken too soon. Yes, the SEGMENT violation is gone. However,
I stumbled upon this. I define three distinct vectors *WS*, *WD*, and D.
Then I compute the following
(dot *ws* d): 5.771771444577276d0
(dot *wd* d): #C(0.0d0 -8.946814341083627d0)
(/ (m:dot *wd* d) (m:dot *ws* d)): #C(1.0d0 0.0d0)
==> THIS SHOULD HAVE BEEN #C(0.0D0 -1.5500985142939754D0) <==
Now what? I'm clueless on how to track this one down.
mike
;;; Here is the test file I used...
(defparameter *ws*
(m:make-complex-matrix '(
0.1950
0.2268
0.3161
0.4467
0.5964
0.7425
0.8661
0.9544
1.000
1.000
0.9544
0.8661
0.7425
0.5964
0.4467
0.3161
0.2268
0.1950)))
(defparameter *wd*
(m:make-complex-matrix '(
0.2316
0.3783
0.6041
0.8240
0.9720
1.000
0.8755
0.5988
0.2126
-0.2126
-0.5988
-0.8755
-1.000
-0.9720
-0.8240
-0.6041
-0.3783
-0.2316 )))
(defparameter d
(m:make-complex-matrix '(
#C( -6.8643E-1 -7.2719E-1)
#C( -4.6423E-1 -8.8572E-1)
#C( -2.0744E-1 -9.7825E-1)
#C( 6.4808E-2 -9.9790E-1)
#C( 3.3222E-1 -9.4320E-1)
#C( 5.7489E-1 -8.1823E-1)
#C( 7.7472E-1 -6.3230E-1)
#C( 9.1684E-1 -3.9926E-1)
#C( 9.9064E-1 -1.3648E-1)
#C( 9.9064E-1 1.3648E-1)
#C( 9.1684E-1 3.9926E-1)
#C( 7.7472E-1 6.3230E-1)
#C( 5.7489E-1 8.1823E-1)
#C( 3.3222E-1 9.4320E-1)
#C( 6.4808E-2 9.9790E-1)
#C( -2.0744E-1 9.7825E-1)
#C( -4.6423E-1 8.8572E-1)
#C( -6.8643E-1 7.2719E-1))))
(format t "(dot ws d): ~A~%" (m:dot *ws* d))
(format t "(dot wd d): ~A~%" (m:dot *wd* d))
(format t "(/ (m:dot *wd* d) (m:dot *ws* d)): ~A~%" (/ (m:dot *wd* d) (m:dot *ws* d)))
|
|
From: Raymond T. <to...@rt...> - 2002-07-26 17:27:37
|
>>>>> "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.
This is very, very weird. I'll look in to it. And actually, it's an
error in (dot complex complex) since you've created *ws* and *wd* as
complex matrixes. Some weird problem since it computes the individual
dots correctly.
Ray
|
|
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
|
|
From: Raymond T. <to...@rt...> - 2002-07-26 21:39:40
|
>>>>> "Raymond" == Raymond Toy <to...@rt...> writes:
Raymond> In any case, I think the following solves the immediate problem:
Raymond> (defmethod dot ((x complex-matrix) (y complex-matrix) &optional (conjugate-p t))
Raymond> (let* ((nxm (number-of-elements x))
Raymond> (store-x (store x))
Raymond> (store-y (store y))
Raymond> (dot (if conjugate-p
Raymond> (zdotc nxm store-x 1 store-y 1)
Raymond> (zdotu nxm store-x 1 store-y 1))))
Raymond> (if (zerop (imagpart dot))
Raymond> (realpart dot)
Raymond> (complex (realpart dot) (imagpart dot)))))
Raymond> I think this need to be fixed in ffi-cmu.lisp in some way. There's no
Raymond> telling what other bugs will be found because of this, if I'm right.
I've committed a fix to ffi-cmu.lisp. I'd appreciate it if you can
try it out. It works for me. :-)
I hope Tunc will try your example with ACL to see if the same bug
exists there.
Ray
|
Thanks for helping keep SourceForge clean.
X