One can see which external compiled function Maple's LinearAlgebra:-Eigenvectors uses, for a generalized eigenvector problem A.x=lambda.B.x where A is symmetric floating-point and B is symmetric positive-definite floating-point.

> A := Matrix(1,shape=symmetric,datatype=float):
> B := Matrix(1,shape=symmetric,datatype\
> =float,attributes=[positive_definite]):
> infolevel[LinearAlgebra]:=1:
> LinearAlgebra:-Eigenvectors(A,B):
Eigenvectors:   "calling external function"
Eigenvectors:   "NAG"   hw_f02fdf

A web search for f02fdf gives this link which documents that function. It says, of the parameter array B, "the upper or lower triangle of B (as specified by UPLO) is overwritten by the triangular factor U or L from the Cholesky factorization of B".

This suggests that, with the shape and attributes on Maple Matrices A and B as in the example above, LinearAlgebra:-Eigenvectors will use a method involving the Cholesky facorization of B. It goes on to say, in the Further Comments section, "F02FDF calls routines from LAPACK in Chapter F08."

For some years now, Matlab has been using LAPACK. See this link from 2000 for an early note on that. It appears from a mirror of the release notes of Matlab 6.0 that the eig function was enhanced to solve exactly the same positive-definite symmetric generalized eigenproblem with the syntax eig(A,B,'chol').

I wouldn't be surprised if these two products schemes were not (at least when originally introduced) very similar implementations of an alternative to the usual QZ/QR algorithm. Notice however a difference in behaviour of the two systems. In Maple it is the shape and attributes of the Matrices whch allow the routine to select the algorithm. The algorithm cannot otherwise be forced. In Matlab the data is pretty much without qualities, and no clever method deduction can be done I think. But the method can be forced by an option to the routine.

ps. Is "without qualities" an eigen-pun, in German? Is the word qualities better translated here as Qualitaten or as Eigenschaften?

acer

Thank you very much. How did you know to do that? From somewhere here on mapleprimes, or just experience with maplenet?

acer

Thank you very much. How did you know to do that? From somewhere here on mapleprimes, or just experience with maplenet?

acer

This sounds similar to a known issue with Maple 9.5, which was addressed in the point-release 9.5.2.

acer

Those advanced mathematical propositions are not within the scope of evalb's design or purpose.

They are not even within the current scope of the "mathematical" verifier `is`. (I don't see a continuous property or type, so I suppose that `is` couldn't make use of an assumption such as D(F)::continuous.) It would be lovely to learn that I'm wrong on that point.

acer

Those advanced mathematical propositions are not within the scope of evalb's design or purpose.

They are not even within the current scope of the "mathematical" verifier `is`. (I don't see a continuous property or type, so I suppose that `is` couldn't make use of an assumption such as D(F)::continuous.) It would be lovely to learn that I'm wrong on that point.

acer

The loop has n go from 1 to N.

Each time through the loop it computes y[n+1] for the current value of n.

The last (Nth) time through the loop, n=N.

So the last (Nth) time through, it computes y[N+1].

acer

The loop has n go from 1 to N.

Each time through the loop it computes y[n+1] for the current value of n.

The last (Nth) time through the loop, n=N.

So the last (Nth) time through, it computes y[N+1].

acer

I figured it out. Suppose that I'm editing a page as Filtered HTML, and even Preview it. Then I accidentally click and go to some other page. Then I hit the back-button to return to the editor & Preview. At that point, the Input format is switched to Plain text and I must remember to set it back to Filtered HTML. It's a minor bug.

Thanks very much for switching it for the above post, Scott.

acer

I am sure that I posted the above item with "input format" as "Filtered HTML", because I checked the links directly from the Previewed display. But now it appears (to me, at least) as plaintext.

acer

Yes, this is numerical DE solving.

Some links to help in understanding the relationship to numerical integration are here and here. Those pages have even more links to follow on the topic.

acer

Yes, this is numerical DE solving.

Some links to help in understanding the relationship to numerical integration are here and here. Those pages have even more links to follow on the topic.

acer

It appears as if he wants to use the Classic GUI. Since that's not available on OSX, he thought that perhaps he could use Maple for Linux instead.

As someone pointed out, Linux (ELF format) binaries don't run natively on an OSX machine (even if its architecture is Intel) so he might instead try running Linux as a virtual operating system.

I guess that there isn't any sort of mechanism to run Linux binaries directly under OSX, in say the same way that lxrun could run them on an Intel-Solaris system. Who knows, maybe lxrun will get ported to OSX...?

acer

There is a possible undesirable side-effect of using `assign` to zip together two Matrices.

Recall, the suggestion was zip(assign,A,B) or similar, where Matrix A had entries like a[1,1], etc. Suppose that a[1,1] were already assigned a symbolic (name) as its value. The zip would then assign to that underlying name! That's probably not what you might want to bring about.

For example, look what happens to name d below,

> A:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(assign,A,B):
> A, a[1,1], d;

                                [3    0]
                                [      ], 3, 3
                                [4    4]

But maybe we can construct a safer procedure to use for the zipping, which doesn't also assign to name d as a more extensive side-effect.

> restart:

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> A:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(p,A,B):
> A, a[1,1], d;
                                [3    0]
                                [      ], 3, d
                                [4    4]
 

Now what about your claim, that assignments into the named entries of C don't carry through to those of A. As long as the named entries are the same, then it does seem to work fine. For example,

> restart:

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> A:=Matrix(3,3,symbol=a):
> C:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(p,C,B):
> A, a[1,1], d;

                     [   3          0       a[1, 3]]
                     [                             ]
                     [   4          4       a[2, 3]], 3, d
                     [                             ]
                     [a[3, 1]    a[3, 2]    a[3, 3]]

All I can think of, is that maybe your C and A contained different symbolic 'a'. Maybe one of them contained the members of global table 'a' while the other had some local 'a', or maybe each had different local 'a' entries.

Now on to your example where the zipping of `assign` didn't work when target C had sparse storage.

> restart:

> C:=Matrix(2,2,[[a[1,1],0],[a[2,1],0]],storage=sparse);

                                   [a[1, 1]    0]
                              C := [            ]
                                   [a[2, 1]    0]
 
> B:=Matrix([[3,0],[4,4]]):

> zip(assign,C,B):
Error, (in assign) invalid arguments

> C;

                                [   3       0]
                                [            ]
                                [a[2, 1]    0]

The assignment to C failed after the (1,1) entry was assigned to. But it couldn't assign to 0, and aborted with an error. The examples above hint at why it might fail. It's unable to bring about the more extensive side-effect on 0 which is not a name. The procedure `p` helps here too.

> restart:

> C:=Matrix(2,2,[[a[1,1],0],[a[2,1],0]],storage=sparse);

                                   [a[1, 1]    0]
                              C := [            ]
                                   [a[2, 1]    0]

> B:=Matrix([[3,0],[4,4]]):

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> zip(p,C,B):
> C;

                                   [3    0]
                                   [      ]
                                   [4    0]

acer

There is a possible undesirable side-effect of using `assign` to zip together two Matrices.

Recall, the suggestion was zip(assign,A,B) or similar, where Matrix A had entries like a[1,1], etc. Suppose that a[1,1] were already assigned a symbolic (name) as its value. The zip would then assign to that underlying name! That's probably not what you might want to bring about.

For example, look what happens to name d below,

> A:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(assign,A,B):
> A, a[1,1], d;

                                [3    0]
                                [      ], 3, 3
                                [4    4]

But maybe we can construct a safer procedure to use for the zipping, which doesn't also assign to name d as a more extensive side-effect.

> restart:

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> A:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(p,A,B):
> A, a[1,1], d;
                                [3    0]
                                [      ], 3, d
                                [4    4]
 

Now what about your claim, that assignments into the named entries of C don't carry through to those of A. As long as the named entries are the same, then it does seem to work fine. For example,

> restart:

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> A:=Matrix(3,3,symbol=a):
> C:=Matrix(2,2,symbol=a):
> d:='d':
> a[1,1]:=d:
> B:=Matrix([[3,0],[4,4]]):
> zip(p,C,B):
> A, a[1,1], d;

                     [   3          0       a[1, 3]]
                     [                             ]
                     [   4          4       a[2, 3]], 3, d
                     [                             ]
                     [a[3, 1]    a[3, 2]    a[3, 3]]

All I can think of, is that maybe your C and A contained different symbolic 'a'. Maybe one of them contained the members of global table 'a' while the other had some local 'a', or maybe each had different local 'a' entries.

Now on to your example where the zipping of `assign` didn't work when target C had sparse storage.

> restart:

> C:=Matrix(2,2,[[a[1,1],0],[a[2,1],0]],storage=sparse);

                                   [a[1, 1]    0]
                              C := [            ]
                                   [a[2, 1]    0]
 
> B:=Matrix([[3,0],[4,4]]):

> zip(assign,C,B):
Error, (in assign) invalid arguments

> C;

                                [   3       0]
                                [            ]
                                [a[2, 1]    0]

The assignment to C failed after the (1,1) entry was assigned to. But it couldn't assign to 0, and aborted with an error. The examples above hint at why it might fail. It's unable to bring about the more extensive side-effect on 0 which is not a name. The procedure `p` helps here too.

> restart:

> C:=Matrix(2,2,[[a[1,1],0],[a[2,1],0]],storage=sparse);

                                   [a[1, 1]    0]
                              C := [            ]
                                   [a[2, 1]    0]

> B:=Matrix([[3,0],[4,4]]):

> p := proc(a::evaln,b)
>   if type(eval(a,2),name) then
>     assign(eval(a,2),b);
>   end if:
>   NULL;
> end proc:

> zip(p,C,B):
> C;

                                   [3    0]
                                   [      ]
                                   [4    0]

acer