Recent changes to 2634: zgeev does not operate on real matriceshttps://sourceforge.net/p/maxima/bugs/2634/2013-11-16T11:25:42Z#2634 zgeev does not operate on real matrices2013-11-16T11:25:42Z2013-11-16T11:25:42ZDominik Wondrouschhttps://sourceforge.net/u/dwondrousch/https://sourceforge.net0b9056b8b469831226307611a245661e697ef141<div class="markdown_content"><p>Thanks a lot. You are awesome !</p></div>#2634 zgeev does not operate on real matrices2013-10-07T17:05:29Z2013-10-07T17:05:29ZRobert Dodierhttps://sourceforge.net/u/userid-501686/https://sourceforge.netab47e8c6c3b57dead1b55eae2cc5f8f8e02f08f5<div class="markdown_content"><ul>
<li><strong>status</strong>: open --> closed</li>
</ul></div>#2634 zgeev does not operate on real matrices2013-09-18T23:08:02Z2013-09-18T23:08:02ZRobert Dodierhttps://sourceforge.net/u/userid-501686/https://sourceforge.net3e93d47a1461a9cea4e355ed842fa838a51abb0c<div class="markdown_content"><ul>
<li><strong>summary</strong>: zgeev does not operate on real matrices + feature request for zheev --> zgeev does not operate on real matrices</li>
<li>Description has changed:</li>
</ul>
<p>Diff:</p>
<div class="codehilite"><pre><span class="gd">--- old</span>
<span class="gi">+++ new</span>
<span class="gu">@@ -32,5 +32,3 @@</span>
Always reproducible.
Also, zgeev is NOT documented in the help file, but dgeev is. Found it's existance via google search in the feature requests.
<span class="gd">-</span>
<span class="gd">-Second, I'd like to address a feature request. Could you implement an interface to zheev as well ? This is the same thing for complex hermitian matrices. Although one can solve the same problems using zgeev, there is a significant difference: zgeev does NOT orthonormalize eigenvectors for degenerate eigenvalues, zheev does because herimitian eigenvectors are supposed to be orthonormal. I know, there is gramschmidt, but using the numerical results of zgeev, this turns out to be numerically instable.</span>
</pre></div>
</div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-18T03:55:47Z2013-09-18T03:55:47ZRaymond Toyhttps://sourceforge.net/u/rtoy/https://sourceforge.net2ec8e3875c34d724f01f189f9689b8ae732b3898<div class="markdown_content"><p>I still think it should be done on a different level. And while the user can't simply add 0.0*%i to force a complex value, the user can check if imagpart() is non-zero for some matrix element.</p>
<p>Are we going to make zgeev magically determine the matrix is hermitian and call zheev instead? Certainly possible, but I really think this should all be done at a different level instead of at the lapack routine level.</p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-18T02:28:52Z2013-09-18T02:28:52ZRobert Dodierhttps://sourceforge.net/u/userid-501686/https://sourceforge.net68625760c4d7af63562e679b030b0e328a6f54d3<div class="markdown_content"><p>@Dominik: thanks for the suggestion about zheev, but in general I'm pretty sure it's best to separate different topics into different messages.</p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-18T02:26:39Z2013-09-18T02:26:39ZRobert Dodierhttps://sourceforge.net/u/userid-501686/https://sourceforge.net2624686eed7a18339fa417201d84004bdb6d9772<div class="markdown_content"><p>Actually I think it is absolutely required that zgeev accept real numbers as input, since there is no way, at the user level, to construct a complex number which has zero imaginary part -- Maxima will simplify away any term <code>0*%i</code>.</p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-17T15:44:03Z2013-09-17T15:44:03ZDominik Wondrouschhttps://sourceforge.net/u/dwondrousch/https://sourceforge.net20e520f45cd53a5499552566919d445e98c0b06e<div class="markdown_content"><p>I am sorry for sounding to be a bit nagging, but I still do not get the point. </p>
<p>When programming in C++ or FORTRAN and using LAPACK's routines, the programmer would definitely know how to treat the generated data - as real or as complex, so it is clear which to call: dgeev or zgeev. </p>
<p>In Maxima, the evaluation of a matrix may result in a complex or a real type. As in my case, </p>
<blockquote>
<p>S: genmatrix(lambda(<span>[i,j]</span>,integrate(demoivre(conjugate(B<span>[i]</span>)*B<span>[j]</span>),x,0,1)),length(B))</p>
</blockquote>
<p>results in a complex hermitian matrix S with a user-provided set of functions B. But for Maxima, S could turn out to be real, given a special case of B. While programming in C++ or FORTRAN, one could simply treat S as being complex anyway because the compiler will not care for a+%i*b being in fact real for b=0. But Maxima will care. If the computation of S<span>[i,j]</span> is real for all i,j then S will be treated as real matrix and can't be used with zgeev anymore. And this incompatibility only depends on the (user-provided and hence unknown) choice of function array B. </p>
<p>I am totally fine with zgeev to be a bare interface to LAPACK. But if done so, an automatic conversion from real to complex should take place (although dgeev may give better results. If you insist, print a warning.) This is the equivalent of the C++ or FORTRAN case of storing real values in complex matrices by setting the imaginary part to zero and using (knowingly) the zgeev function. The knowledge, that the provided Maxima matrix is in fact real, is an artifact of how Maxima treats its equations, and should therefore be ignored in case explicit complex evaluation is requested.</p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-17T02:25:22Z2013-09-17T02:25:22ZRaymond Toyhttps://sourceforge.net/u/rtoy/https://sourceforge.net016f1c787d9feda33b634135245ccc5aa77088f8<div class="markdown_content"><p>Well, it was never really intended that dgeev and zgeev be the actual user interface to LAPACK. This interface was intentionally designed to be a relative bare interface to the LAPACK routines so you could just look at the LAPACK documentation and guess what to do.</p>
<p>The actual interface would have been something at a higher-level appropriate for maxima, possibly hiding, or selecting, the appropriate routine to use.</p>
<p>So far, no one has stepped up to design such an interface. :-(</p>
<p>I'm not completely opposed to making zgeev smarter, but I would really prefer that to be done somewhere else. Obviously, the pain of zgeev hasn't motivated anyone to make a better interface.</p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-16T16:24:25Z2013-09-16T16:24:25ZDominik Wondrouschhttps://sourceforge.net/u/dwondrousch/https://sourceforge.net236c2d75b3cb3a7019fa8635967dc6b776ec8761<div class="markdown_content"><p>I you don't mind, I'd like to disagree. It is always possible that by chance of computation or unknown user input a matrix, which is normally considered complex, turns out to be real instead. Taking your suggestion into account would result in somewhat tedious scripting: For each time one would instinctively call zgeev, one would have to check for calling dgeev or zgeev, respectively, depending wether all elements of imagpart are zero or not.</p>
<p>It may be true that dgeev should be prefered over zgeev for real matrices, but in case one does not know the nature of the argument it is natural to call for the most general case which is zgeev because all real numbers are complex numbers as well.</p>
<p>As a compromise, Maxima's zgeev could do a check for real matrices and call dgeev instead, but this may result in an unexpected deviation from LAPACK's standard behaviour. </p></div>#2634 zgeev does not operate on real matrices + feature request for zheev2013-09-16T02:07:40Z2013-09-16T02:07:40ZRaymond Toyhttps://sourceforge.net/u/rtoy/https://sourceforge.netf71fd037df05f8354760ea9a9303a824373ef311<div class="markdown_content"><p>I will update the documentation for zgeev. I will also look into adding zheev; that seems like a useful addition to zgeev.</p>
<p>I think zgeev should only accept complex-valued data. I suspect that dgeev would be faster and probably more accurate than using zgeev. If you disagree, please bring this up on the mailing list.</p></div>