Re: 2 fail with tip chol.cc

[Jaroslav Hajek]

On Fri, Jan 21, 2011 at 4:59 PM, John W. Eaton <address@hidden> wrote:
> On 21-Jan-2011, Doug Stewart wrote:
>
> |  src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS   72/72
> |   src/DLD-FUNCTIONS/cellfun.cc ........................... PASS   77/77
> |   src/DLD-FUNCTIONS/chol.cc .............................. PASS   24/26
> | FAIL 2
> |   src/DLD-FUNCTIONS/conv2.cc ............................. PASS    4/4
> |   src/D
>
> I traced this back to products like X'*X, which are giving me
> uninitialized data errors when X is complex.  I can generate the
> errors with something as simple as
>
>  X = [ 0.5585528 + 0.0000000i  -0.1662088 - 0.0315341i;
>       -0.1662088 + 0.0315341i   0.6760061 + 0.0000000i];
>
>  X'*X
>
>  Y = single (X);
>
>  Y'*Y
>
> It does not seem to be a problem for real-valued matrices.
>
> The following patch avoids the problem for me, but looking at CHERK in
> the reference BLAS, I doesn't appear that it should be necessary to
> initialize the output matrix C if BETA is zero, so this looks like it
> might be a bug in ATLAS.
>
> I'm also attaching a Fortran program that will show the problem on my
> system if I link with ATLAS (I have the libblas3gf package on a Debian
> amd64 system).  When I use the reference BLAS version of CHERK, I
> don't see a problem.
>
> Jaroslav, can you duplicate this problem?  Would you prefer a
> different fix?  For now, I'm checking in this patch.
>

Yes, some ATLASes have a buggy CHERK, that's a recurring issue. I
don't think your patch actually helps in all cases, because I've seen
stuff like CHERK creating (NaN, 0) on the diagonal :(
This is really something that should be fixed in ATLAS (and maybe it
was fixed, I never got around to try the development version).

In any case, if you're making a workaround that decreases performance,
even if only slightly (such as in this case), I suppose you should
better mark it as a workaround, because it's unlikely that someone
will be able to undo the change later.