On Wednesday, December 5, 2018 at 10:15:52 AM UTC-8, saad khalid wrote:
>
> Thank you all for the thoughtful responses, your comments helped me a lot.
> One last bit of trouble that I've been having related to this topic. This
> was is the code I was running:
>
> Mz = matrix([[0,1],[1,0]])
> Mx = matrix([[1,0],[0,-1]])
> M1 = Matrix([[1,0],[0,1]])
> import numpy as numpy
> #R.<s> = QQ[]
> _ = var('J,hx,alpha')
> alphas = numpy.linspace(0,1,10)
> Bp = Mz.tensor_product(M1).tensor_product(M1).tensor_product(M1) * M1.
> tensor_product(Mz).tensor_product(M1).tensor_product(M1) * M1.
> tensor_product(M1).tensor_product(Mz).tensor_product(M1) * M1.
> tensor_product(M1).tensor_product(M1).tensor_product(Mz)
> Plaqz = Mx.tensor_product(M1).tensor_product(M1).tensor_product(M1)
> F = lambda s: -(1-s)*Bp - s*Plaqz
>
> show(F(.1).eigenvalues())
>
> If I run it, it gives me results with the error: "
>
> UserWarning: Using generic algorithm for an inexact ring, which will probably
> give incorrect results due to numerical precision issues."
>
> I expected this error to be some minute difference in the far out decimal
> place range, like I so often see with
> complex numbers, but the answer I get is actually Quite a bit off from the
> correct answer. Upon googling, i found that this can
> be fixed by appending CDF to the beginning of every matrix definition, like
> this:
>
>
> My question is, why is the default an alg that seems to give incorrect
> answers, instead of just defaulting to CDF?
> Also, is there a better way of doing this besides just appending CDF to the
> beginning every time?
>
> This is actually a real omission in the code. Using ComplextField(...)
instead of CDF is slower but provides more options, for instance working
with more than 53 bits. While computing eigenvalues of matrices numerically
is fundamentally a tricky operation that generally needs care and error
control, there are reasonable strategies to do a lot better than what
happens with ComplexField by default (as you can see with CDF). It would be
really good if matrices over ComplexField and RealField would use
algorithms that at least use some common sense. The warning about imprecise
answers would still apply, but to a much lower degree. (Technical note:
echelonization for CC and RR presently doesn't even use partial pivoting.
If we at least do that, we get something that's a little closer to the
"best effort" result people can reasonably expect.
Of course, by the time you're using numpy anyway, you should probably
prefer to use the state of the art numerical tools offered there. Only if
you need more than 53 bits should you consider the sage types.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
