Two small changes to linalg tests to avoid spurious failures.

[andreasnoack]

No description provided.

[andreasnoack]

The one I deleted is not important. It performes the exact same calculations two times in that chol(A)=factors(chold(A)). Then it checks if the results are the same. They usually are, but sometimes they differ because of floating point noise differences in the two LAPACK calls.

The second test still fails which I cannot really understand. Could there be something wrong with LAPACK on the Travis machine?

[staticfloat]

@andreasnoackjensen; The LAPACK being used is OpenBLAS 0.2.5, compiled and distributed on my PPA. Please feel free to download and test using that .deb if you want to replicate the travis build environment (And be sure to define USE_SYSTEM_BLAS=1, USE_SYSTEM_LAPACK=1).

I'm changing around some organization of my computers right now, to get the 32-bit VM onto a faster machine for more convenient testing. Once I have done that, I'll continue trying to get matrices that fail to you (so far, when I put in the debugging code to spit out the matrices, the error doesn't happen! Intermittent errors are the worst!)

[andreasnoack]

Thank you for the feedback. I have already tried to build Julia in a 32 bit Ubuntu in a VM with your ppa and still I cannot reproduce the error. This time it happened on the clang machine. Have you noticed if the LAPACK error only shows up when compiling with clang?

[staticfloat]

It's true, I don't have an example of it showing up on a gcc build, only clang. I'll see if I can reproduce with gcc instead.

[pao]

This is intended to address #1652 and #1682? Let's get those linked up to this pull request.

You may want to amend the patch to fix "Too" -> "Two" in the commit message.

[andreasnoack]

Success. Maybe the Travis machine just fails on poor spelling in commit messages.

[ViralBShah]

Looks like we need a rebase, so that this can be merged. I don't think I have quite understood how the failing tests passed, and perhaps we will encounter the issue again later.

Green on travis is good enough for me. :-)

[staticfloat]

This looks to me like this closes #1652, but not #1682, my guess is we were just lucky with the latest commit. #1682 is elusive, but I'm still looking into it. I'll ask for help if/when I figure out there's something subtly wrong with our usage of LAPACK on 32-bit. :P

We should still rebase/merge this though, to fix #1652, as that is much more consistent. Floating point math; can't test with it, can't test without it. ;)

[andreasnoack]

It should be ready to merge now.

I agree with @staticfloat. #1682 seems very irregular and I don't think the change of seed will change that.

[andreasnoack]

Ah. Those numbers. I shouldn't commit before breakfast. I meant #1652 (LAPACK convergence) is still a problem but #1682 solved.

[pao]

@staticfloat said the same thing, so I didn't check. Well, what's done in the commit message is done. I'll fix the issues.

[staticfloat]

I..... wow. Yes, we both just did that.
-E