Why is there a space between the z and the [i] ?

> [1]:=4;
Error, illegal use of an object as a name

> r[1]:=4:
> r[2]:=-7:
> r[3]:=2:
> r[4]:=-1:

> r := convert(r,list);
                         [4, -7, 2, -1]

> min(r);
                               -7

> x := ListTools:-Search(min(r),r);
                               2

That should work if `r` is originally a table, list, or Vector. If it's a really big Vector, then it might be faster to use rtable_scanblock.

Is this good enough?

> A := Matrix([[1, -2, 0], [-2, 13, -11], [0, -11, 21]]):

> LinearAlgebra:-Transpose(
>    LinearAlgebra:-LUDecomposition(A,output='U'),'inplace');

                                [ 1    0   0]
                                [           ]
                                [-2    9   0]
                                [           ]
                                [         68]
                                [ 0  -11  --]
                                [         9 ]

You might do the same with LUDecomposition's `L` factor as well. And LUDecomposition will permute for stability, for floats. And it'll call Normalizer/Testzero for symbolics.

The assignment to the indexed omega turns omega into a table (which thus overwrites its earlier assigned value).

Note that there are two objects (underneath) that display as a subscripted name. One of them is an indexed name like omega[h]. The other is a subliteral (aka "atomic identifier" or atomic name). The default, when you enter a subscripted name by typing the keystrokes omega_h is the indexed name.

It is possible to use both omega and subscripted omega at the same time, without the value clobbering that you've experienced. But to do so you must use the atomic identifier form of the subscripted omega.

You can get this in either of two ways. 1) Enter it using the "subliteral" item on the Layout palette. 2) Enter it as usual, but before hitting Return/Enter use the mouse pointer to select it, and then convert by the context-menu choice 2-D Math -> Convert To -> Atomic Identifier. You must enter each and every instance of subscripted omega_h in either of those ways, or via copy 'n paste, or else it will be the indexed name omega[h] instead.

There is no convenient way to tell which is which, by looking at what is displayed (unless you once again use the mouse, delve a few levels in the context-menus, and check whether the Atomic Identifier entry is checked off.) That is not helpful.

The Layout palette's "subliteral" entry was changed in Maple 14. It's hover-over tooltip now shows as `A[n]`; which is very misleading and thus unhelpful. Also, this item now gets injected with the subscript being purple, which is also not helpful. And it has been further broken because after injection into the Document the mouse pointer is situated after the whole symbol and not on the basename marker A (as it ought to). With the Layout palette's subliteral entry so broken, a difficult issue is just that much harder.

You're probably better off using a distinct name, as Kamel suggests in his Answer.

> Vector(4, i->i );
                                      [1]
                                      [ ]
                                      [2]
                                      [ ]
                                      [3]
                                      [ ]
                                      [4]

> Vector([seq(i, i=1..4)]);
                                      [1]
                                      [ ]
                                      [2]
                                      [ ]
                                      [3]
                                      [ ]
                                      [4]

> Vector([$1..4]);
                                      [1]
                                      [ ]
                                      [2]
                                      [ ]
                                      [3]
                                      [ ]
                                      [4]

You might also be interested in Vector[row](..) instead of Vector(..) which defaults to creating column Vectors.

This occurs because you are specifically asking Maple to map the squaring operation over the "operands" of the expresion. Your expression x+y is a sum, with two operands which are x and y.

> op(x+y);
                                    x, y

If you want to merely apply x->x^2 to your scalar expression then it is not appropriate to `map` the operation. Just apply the operation to the expression.

> (x->x^2)(x+y);
                                         2
                                  (x + y) 

The slowdown is caused by `evalhf` not being able to handle your procedure A in Maple 13 or earlier. And so `plot` falls back to using the slower software float `evalf` environment under which to run your procedure A. This is fixed in Maple 14, and you code is fast there. But you seem to have Maple 13, in which your posted code runs more slowly.

This runs quickly even in Maple 13, however,

  plot(unapply(Spikes,Z),0..5,numpoints=100,adaptive=false);

FWIW, I believe that one of the things in your `A` that is causing `plot` to fall out of `evalhf` and back to merely `evalf` is the eval(Spikes,Z=zz) line.

As a general rule, there is no point to creating a procedure B if you're only going to ever invoke it like B(t). Several numeric commands like plot, fsolve, Optimization minimize accept the "operator" calling sequence which I used above. If I had earlier assigned unapply(Spike,Z) to B then I could call plot(B,0..5) etc.

Is there some reason that you don't want to use the `subs` command itself? There is not usually a distinction on what `subs` can act upon; objects are (pretty much) the same underneath whether they are displayed as 1D input or 2D output, etc.

There are some exceptions, in what DynamicSystems routines display, but that may not be your case. Tell us if you are in fact trying to operate on what some DynamicSystems command has returned, because some of those commands display only a "faked" display of some returned object. Their returned objects are, in some cases, modules whose content needs to be accessed using special syntax. It's hard to tell yet whether this is your situation.

Or is it more that you simply don't want to have typed-in programming commands in your Document? Maybe you want it all clickable-math and so forth? If that is true then you could use the right-click context-menus to act upon your expression. You could choose "Apply a Command" and use `subs` in the popup entry box, or you could choose "Evaluate at a Point" and supply `s` and your new variable name in that popup box. The decision to enable self-documenting context-menu actions would also be yours to make, to control whether the resulting arrow had the name of the action printed above it.

BTW, the imaginary unit is I, not i, by default. So you'd want to substitute in I*omega.

I am supposing that you've written omega_2 to mean a subscripted omega. If so, then it's easier to do many of these (different omega_i) together, since indexed table references are displayed subscripted. (Even if that's not the case, it can still be set up together, using `cat` to combine a base name with `i`. It's just a little more code.)

Using `alias`

> restart:

> alias(seq(alpha[i](t)=diff(omega[i](t),t),i=1..3)):

> expr := diff(omega[2](t)+omega[3](t),t);
                   alpha[2](t) + alpha[3](t)

Using `eval`

> restart:

> expr := diff(omega[2](t)+omega[3](t),t);
             / d             \   / d             \
             |--- omega[2](t)| + |--- omega[3](t)|
             \ dt            /   \ dt            /

> difflist := [seq(diff(omega[i](t),t)=alpha[i](t),i=1..3)]:

> eval( expr, difflist ); 
                   alpha[2](t) + alpha[3](t)

As you can see, it's more "automatic" with that `alias` method.

In what range (general magnitude of x) did you expect to find a solution?

Look at how many times your code converts the same value to base 7. You could save Maple time and resources by just computing that once, assigning the result to some variable, and then re-using that.

The same thing goes for those nops() calls. You should not repeat such nops() calls with the very same argument if you can avoid it, especially if what is inside the nops() involves a computation.

Also, the bits inside the nops() are inefficient. The nops of the rotation or reversal of a list is just going to be the same as the nops of the list itself. So don't make Maple repeat all that rotation/reversal each time, just to apply nops() to it.

You don't need to reverse or rotate the list, just to add up the digits multiplied by powers of 10. Instead of rotating/reversing, just re-do the formula in which the index `j` gets used, like for the power of 10.

Maybe consider a ceil() of a log[7] or something (with floats?), rather than nops of a base 7 conversion (which has to produce the whole `list` of digits as an unneeded temporary object). Not sure how much better this is (or is not) at various magnitudes.

This is not a "Mac" issue.

It's how Documents work.

If you don't care for the behaviour you've seen, then change to Worksheets instead, in the same Standard GUI. If you do that then the display timing will work as you expect, in your Maple 11.

You can set it so that all new sheets are Worksheets instead of Documents by default.

Or you can always open either type at any moment, directly, using the menus.

It's not a 2D vs 1D thing. It's a Document vs Worksheet thing.

If it's of interest to you, in Maple 14 Documents work the same way for the example exactly as you describe it.

This sounds a bit like general Java redrawing speed issues. For which you could buy a faster processor, but not much else in terms of hardware solutions. More RAM likely won't help, unless you have so little that Standard is always a problem even for minor computations. Your 2.5GB or RAM sounds fine.

You could also try using an alternate graphical Maple interface not based upon Java, such as Classic. On a new high end i7 the Standard (Java) GUI starts and is ready to accept typed input in just a few seconds. But it still slows down and pumps mud when given too many plots and 2D output lines, even with a "gamer" video card.

This is one of the real reasons that some people stick with Classic. It's not a 2D vs 1D math usability thing. It's a performance question, for more "full" worksheets. (2D typesetting and rendering can contribute to the performance "problem", but 2D Math look & feel & usability is not the issue at hand.) Performance of Standard has improved over the past 5-6 years, in terms of start-up speed and manipulation of small short worksheets. But add in too may plots and output, and it still falls down.

More responsive Maple GUIs might be built on top of Qt or FLTK. (See here, on a choice made WRI.) I doubt that anyone except Maplesoft could do that properly for Maple unless all the kernel-GUI streams were fully documented and available in OpenMaple. And right now that is far from true.

You could send your worst performing examples to Maplesoft tech support, since if nobody does so then such issues which manifest only on involved worksheets/documents are much less apparent.

See the help page ?plots,contourplot

You can do it like you've described. But you can also just use the LeastSquares command.

> restart:
> with(LinearAlgebra):

> M := RandomMatrix(607,400,generator=0.0..10.0):
> B := RandomVector(607,generator=0.0..1.0):

> X1 := LeastSquares(M, B):
> res1 := M . X1 - B:
> add( res1[i]^2, i=1..607 );
                   20.31481555375303

> Norm( M^%T . (B - M . X1) );
                                         -13
                   4.52970994047063869 10   

> X2 := (M^%T . M)^(-1) . M^%T . B:
> res2 := (M . X2 - B):
> add( res2[i]^2, i=1..607 );
                   20.31481555375302

> Norm( M^%T . (B - M . X2) );
                                         -11
                   4.29691837666723586 10   

By the way, you may want to rethink what you wrote about the dimensions of B being 400x1, instead of 607x1.

Now, to slice up 400x1 Vector X into four pieces.

> for i from 1 to 4 do
>   piece[i] := X1[(i-1)*100+1 .. i*100];
> end do:

> Norm( X1 - Vector([piece[1],piece[2],piece[3],piece[4]]) ); # test it
                               0.