Re: MuPad 3.0 extraction of individual eigenvectors

From: Christopher Creutzig (ccr_at_mupad.de)
Date: 11/12/04 

Date: Fri, 12 Nov 2004 16:31:46 +0100

Brad Cooper wrote:

> John's idea of point and click to extract arguments has merit. Of course you
> still want procedures you can embed in code that you may need to write. In
> that case, the aforementioned use of op, map and indexing is still required.

  I may have misinterpreted John, but I thought he was talking about a
way of asking MuPAD “if I wanted to extract this, what call would I
need?” I'm not sure how a user interface would look like that allows
to make this question sufficiently generic. (In the case at hand, the
answer should not have been “[Sol[1][3][1], Sol[1][3][2], Sol[2][3][1]]”
instead of the map call, yet building this call requires some more
insight into the nature of the problem than having some subexpressions
marked.)

> This leads me to thinking a How To document with several examples would be
> very useful. It is often the case that a user of MuPad does not want to
> simply take output from a command to MuPad, but the user often wants do
> something with it i.e. feed it into another command.

  As Torsten wrote: What should these examples be? For example, I have
absolutely no idea why someone would try to put the eigenvectors of a
matrix into linalg::orthog. Obviously, the resulting vectors will in
general not be eigenvectors any longer:

>> A := matrix([[1,2,3],[4,5,6],[9,8,7]]):
>> S := linalg::eigenvectors(A):
>> P := linalg::orthog(map(S, op@op, 3)):

// This call is what I mean, but it triggers a bug in Dom::Matrix,
// which I already sent to the persons in charge of matrices:
// >> zip(A*P[2], P[2], normal@`/`)
// So I do it this way:

>> zip([op(A*P[2])], [op(P[2])], normal@`/`)

         -- 1/2 1/2 1/2 --
         | 54 313 - 810 117 313 - 1953 156 313 - 3000 |
         | ---------------, -----------------, ----------------- |
         | 1/2 1/2 1/2 |
         -- 313 - 103 7 313 - 127 13 313 - 151 --
>> float(%)

                 [-1.703910468, -37.03770902, -3.039216243]

  I do agree that MuPAD's various functions do not yet do a really good
job of accepting one another's output, but as for transforming them,
I'm afraid the main problem is finding good examples of things that can
be explained, yet do not work out of the box anyway.

> showing by example what to do may be useful. For example, I was unaware of
> op@op which is a nice little nick nack described in this current set of
> newsgroup replies.

  Granted, the only examples using map(A, f@g) in the tutorium are in the
answers to exercises. Perhaps I should add a few of these where map is
introduced.

> BTW thanks to you guys for your really clear and helpful replies.

  It's always a pleasure to do so. (I know I hadn't raised my fingers
in this thread yet.)

Regards,
        Christopher Creutzig

Relevant Pages