`isposdef` inconsistent results, numerically unstable?

[ChrisRackauckas]

I thought I just mentioned it here:

Approximate equality

I read somewhere that the approximation binary operator (\approx) checks if the number is within machine precision. Whatever it does exactly, it does not appear to behave consistently: julia> ℯ^(-π*im) -1.0 - 1.2246467991473532e-16im julia> ℯ^(-π*im) == -1 false This is probably normal behaviour, and I guess that \sim 10^{-16} is machine or type precision. So I will use \approx to get a trueth, but reordening of symbols, or considering only the imaginary part, results in a falsehood: julia>…

But I guess not. Order of operations matters when taking into account floating point error. Multithreading can change the order of operations, making the multithreaded results stochastic in the last few values due to changing floating point error. I’m not sure what eigs is calling but I would assume that’s what’s happening here.

@mohamed82008

And finding the whole eigenvalue decomposition is overkill.

I would’ve suggested iterative solvers, but they find the eigenvalues in the other order…