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

I was unable to use the Editor (and add content to a comment) when using Netscape 7.2 (or mozilla, or Epiphany) on Linux.

But now, with firefox 2.0.0.11 for i686 Linux the Editor works fine.

Thank you for all the cool new features, Will.

acer