Without specifying the dimensions as arguments the calls Matrix([[]]) and Matrix([]) each produce a Matrix with 1 row and 0 columns.

The calls Matrix() , Matrix(0,0,[[]]) , Matrix(0,0,[]) and Matrix(0,0) each produce a Matrix with 0 rows and 0 columns.

You can build a Matrix with 0 rows and 1 column with the call Matrix(0,1) but I don't see how that could be produced by the Matrix command without specifying the dimensions explicitly in the call. (It can be done with the angle-bracket constructors, though.)

I suspect that your intended meaning for your first sentence is wrong. It's hard to be sure since the grammar is poor.

Why don't you tell us what you're trying to accomplish?

acer

This is a good question, because the displayed result from Maple are unattractive and not close to the beautiful results obtainable with some other software. I'm not aware of any very simple fix, even for configuring the node shapes.

Additional customizability would be a far better solution than would yet another hard-coded look&feel.

While that doesn't sound very encouraging, I think that additional pressure by the community to get it made a priority would not hinder progress.

acer

A little more can be squeezed out of this orange. The interpretation of positions along the curve as the sum of coordinates from three contributing circles includes a choice. For any particular set of values the order of the nesting of the circles is a matter of choice. Considered as the sum of three vectors, the end-point doesn't depend on the order in which the three contributing terms are added.

I refactored the code somewhat, to make choosing the order of nesting of the circles simpler to implement.

restart:

cycler := proc(k, p, m, n, T,
               {showcircles::truefalse:=false, showlines::truefalse:=false,
                showaxes::truefalse:=false, forceview::truefalse:=true,
                nesting::string:="B M G"}, $)
  local t, v, c, r, col, tab, terms, perm;
  uses plottools, plots;
  tab := table(["B"=1,"M"=2,"G"=3]);
  terms := [exp(I*t), -exp((k+1)*I*t), I*exp((1-p*k)*I*t)];
  r := [m*n, n, m];
  col := ["black", "magenta", "green"];
  perm := map2(`?[]`,tab,`[]`~(StringTools:-Split(nesting," ")));
  (r,col,terms) := r[perm], col[perm], terms[perm];
  c := eval([seq([Re,Im](add(terms[i]*r[i], i=1..j)), j=0..3)], t=T);
  v := add(abs(r[i]), i=1..3);
  plots:-display(
    `if`(showcircles,
         [seq(circle(c[i], r[i], ':-linestyle'=':-dot', ':-color'=col[i]), i=1..3),
          pointplot([seq(c[i], i=2..4)], ':-symbol'=':-solidcircle',
                    ':-symbolsize'=15, ':-color'=col)][], NULL),
    `if`(showlines,
         [seq(line(c[i],c[i+1], ':-color'=col[i]),i=1..3)][], NULL),
    complexplot(add(terms[i]*r[i], i=1..3), t=0..T),
    `if`(forceview, ':-view'=[-v..v,-v..v], NULL),
    ':-scaling'=':-constrained',
    ':-axes'=`if`(showaxes, ':-boxed', ':-none') );
end proc:

#cycler(5, 3, 2, 3, 2*Pi, showcircles);

cycler(5, 3, 2, 3, Pi/3, showcircles, showlines);

# The option controller=listbox is new to point release Maple 2015.1 and without
# that option the controller for the nesting parameter `perm` would be a combobox.
# The listbox controller is nice here since its value can be changed while playing.
#
# By selecting different nestings of the three circles (while it plays from
# T=0 to T=2*Pi) it can be seen that the end-point (triple vector-sum) doesn't
# depend on the choice of nesting. That's expected, but nice to visualize.

Explore( cycler(k, p, m, n, T, showcircles=circles, showlines=lines,
                showaxes=boxed, forceview=fullview, nesting=perm),
         parameters = [ [perm = ["B M G","B G M","M B G","M G B","G B M","G M B"],
                         controller=listbox, orientation=vertical, label=nesting],
                        [circles = [true,false], orientation=vertical],
                        [lines = [true,false], orientation=vertical],
                        [boxed = [false,true], orientation=vertical, placement=bottom],
                        [fullview = [true,false], orientation=vertical, placement=bottom],
                        k = -10 .. 10, p = -10 .. 10,
                        m = -10.0 .. 10.0, n = -10.0 .. 10.0,
                        [ T = 0 .. 2*Pi, animate ] ],
         initialvalues = [ k = 3, p = 3, m = 2, n = 4, T = 2*Pi ],
         placement = left, animate = false, loop, numframes = 100 );

acer

@J F Ogilvie Interesting.

The problem with Classic goes away for me using Maple 2015.0 if I remove the option ':-gridlines'=':-false' from the cycler procedure.

That option isn't even a necessary part of the code. I often include it just because the backend maplenet server being used by Mapleprimes had a bug where it always rendered 2D plots with grid lines, unless the option to disabled it were given explicitly.

Individual frames (2D plots) seem to display by themseleves in the Classic GUI. But when gridlines=false is specified then the display as an animation generates an error. I don't see the problem in the Standard GUI.

Here is a revision which hopefully makes the effects of parameters m, n, and p a little more clear.

The ratio of the radius of the magenta circle to the radius of the black circle is 1/m.

The ratio of the radius of the green circle to the radius of the black circle is 1/n.

The rate at which the magenta point travels around the magenta circle is k+1 times the rate at which the black point travels around the black circle.

The rate at which the green point travels around the green circle is p-1 times the rate at which the magenta point travels around the magenta circle.

The black and magenta points both travel counterclockwise around their respective circles, since the corresponding terms in expr share the same sign. The green point travels clockwise around the green circle, with its corresponding term in expr having the opposite sign.

I've rewritten the formula here so that the black circle now has radius n*m, but the explanations involving relative ratios remain pretty much the same. I just thought it might(?) be easier to understand. In the original Post the black circle would have fixed radius of value 1 while the magenta and green circles would get large as m or n became very small.

restart:

cycler := proc(k, p, m, n, T,
               {showcircles::truefalse:=false},
               {showaxes::truefalse:=false},
               {forceview::truefalse:=true}, $)
  local expr, t, u, up, v;
  uses plottools, plots;
  u := exp(k*I*t);
  up := exp(-k*I*t*p);
  expr := exp(I*t)*(m*n-n*u+m*I*up);
  v := abs(m*n)+abs(m)+abs(n);
  plots:-display(
    `if`(showcircles,
         [circle([0,0], m*n),
          circle([m*n*cos(T), m*n*sin(T)], n,
                 ':-linestyle'=':-dot', ':-color'="magenta"),
          circle(eval([Re(exp(I*t)*(m*n-n*u)), Im(exp(I*t)*(m*n-n*u))],
                      t=T), m,
                 ':-linestyle'=':-dot', ':-color'="green"),
          pointplot(eval([[Re(exp(I*t)*(m*n)), Im(exp(I*t)*(m*n))],
                          [Re(exp(I*t)*(m*n-n*u)), Im(exp(I*t)*(m*n-n*u))],
                          [Re(expr), Im(expr)]
                         ], t=T),
                    ':-symbol'=':-solidcircle', ':-symbolsize'=15,
                    ':-color'=["black","magenta","green"])][],
         NULL),
    complexplot(expr, t = 0 .. T, ':-color'="red"),
    `if`(forceview,':-view' = [-v .. v, -v .. v],NULL),
    ':-scaling'=':-constrained', ':-gridlines'=':-false',
    ':-axes' = `if`(showaxes,':-boxed',':-none')
                );
end proc:
cycler(5, 3, 2, 3, 2*Pi);

cycler(5, 3, 2, 3, 2*Pi, showcircles);

Explore( cycler(k, p, m, n, T, showcircles=circles,
                showaxes=boxed, forceview=fullview),
         parameters = [ [circles = [true,false], orientation=vertical],
                        [boxed = [false,true], orientation=vertical],
                        [fullview = [true,false], orientation=vertical],
                        k = -10 .. 10, p = -10 .. 10,
                        m = -10.0 .. 10.0, n = -10.0 .. 10.0,
                        [ T = 0 .. 2*Pi, animate ] ],
         initialvalues = [ k = 3, p = 3, m = 2, n = 4, T = 2*Pi ],
         placement = left, animate = false, numframes = 100 );

And with a traditional animation,

plots:-animate(cycler, [3,3,2,4,t,showcircles], t=0..2*Pi, frames=100);

acer

@J F Ogilvie The revised procedure is defined to expect only five arguments, whereas the original was defined to expect six.

When I revised the procedure to compute with the expression exp(-p*k*I*i) instead of exp(k*I*t)^(-p) I also removed the first procedural parameter `t`. It was just a dummy name, and wasn't otherwise useful.

A revised version of the procedure given as, say,

cycler := proc(k, p, m, n, T) local expr, t, u, up, v;
  u := exp(k*I*t);
  up := exp(-k*I*t*p);
  expr := exp(I*t) * (1 - u/m + I*up/n);
  v := 1 + abs(1/n) + abs(1/m);
  plots:-complexplot( expr, t = 0 .. T, axes = none, color=red,
                      view = [-v .. v, -v .. v] );
end proc:

would be called like so:

cycler(5, 3, 2, 3, 2*Pi);

Note how this differs from the example in the original Post: there is no longer a first (out of six) argument `t`.

That works for me in every recent version of Maple that I can find.

Obviously calling `Explore` on a function call of `cycler` would also need to involve the correct number and type of arguments.

@Carl Love Sure, there is no need to change the name for `t`, so it could be a local. Thanks.

The integer valued parameter `p` adjusts the relative frequency for the opposing term.

The parameters `m` and `n` are just simple scaling factors for the contributing terms.

Here's a reformulation that is more clear, perhaps.

cycler := proc(k, p, m, n, T) local expr, t, u, up, v;
  u := exp(k*I*t);
  up := exp(-k*I*t*p);
  expr := exp(I*t) * (1 - u/m + I*up/n);
  v := 1 + abs(1/n) + abs(1/m);
  plots:-complexplot( expr, t = 0 .. T, axes = none,
                      view = [-v .. v, -v .. v] );
end proc:

Note (not for Carl, who will already have done this in his head),

evalc( exp( k*I*t ) );

                             cos(k t) + sin(k t) I

evalc( exp( -k*I*t*p ) );

                           cos(k t p) - sin(k t p) I

I used only integer values for p. So the two formulations are equivalent. But if parameter `p` were instead set to take on float values then the plots would differ for Pi<t<2*Pi.

simplify( exp(I*t)^(-p) - exp(-p*I*t) ) assuming t>0, t<Pi, p::integer;

                               0

Also, the view=[-v..v,-v..v] adjusts the visible scale "nicely" when animating by duration `t` so that the dynamic scaling is suppressed visibly, and it mostly keeps the display centered but not when k=1. It might be interesting to have a version where `m` and `n` (or their reciprocals, if the whole thing was rescaled?) were Explore "markers" that could be moved around the plot area with the mouse cursor. I haven't looked.

@lham If you want to multiply through by that term then just apply the `expand` command to your expression instead.

@lham I think that it did work for you (and that you also re-executed the command ee:=% a second time after simplifying. Just look at the size of the simplified result compared to the original expression.

@Glowing Is this sufficient? (One could automate this kind of thing. Perhaps someone already has.)

rect.mw

@Carl Love I took the value(K) assuming continuous as it avoided undefined instances in the nested piecewise result, where K was the originally given Int(piecewise(...)).

Compare,

restart:
K:=Int(piecewise(t < T1,
         exp((1/2)*t*(1+2*I-I*sqrt(3))),
                 t < T2,
         -1000*exp((1/2)*t*(1+2*I-I*sqrt(3)))*(-1/1000+T1-t),
                 T2 <= t,
         -1000*exp((1/2)*t*(1+2*I-I*sqrt(3)))*(-1/1000-T2+T1)),
       t):

value(K): # with or without assuming T2>T1
simplify(%) assuming T2>T1;

with,

restart:
K:=Int(piecewise(t < T1,
         exp((1/2)*t*(1+2*I-I*sqrt(3))),
                 t < T2,
         -1000*exp((1/2)*t*(1+2*I-I*sqrt(3)))*(-1/1000+T1-t),
                 T2 <= t,
         -1000*exp((1/2)*t*(1+2*I-I*sqrt(3)))*(-1/1000-T2+T1)),
       t):

value(K) assuming continuous:
simplify(%) assuming T2>T1;

It may not be the only way to get that, though.

The option continuous is not used for indefinite integration, I thought.

Note also the last comment by the OP. The asserted assumption continuous just obscured a problem. Can it be (programmatically) fixed by rejigging with constants of integration? (I haven't looked...)

@casperyc So Mma's SingularValueList would be the right one to test, since the full decomposition (into 3 matrices) provided by Mma's SingularValueDecomposition is not necessary to assess the rank. My supposition -- which I have not yet tried to confirm myself with timings -- is that in at least Mma 10.0.x and earlier the timings for SingularValueList would be very close to those of Rank.

Ok, since typing the above paragraph I went and looked at the Wolfram Language help page for MatrixRank. In its "Properties and Relations" section it says, "MatrixRank[m] is equal to Length[SingularValueList[m]]:". The essential aspect is that the singular values are computed and used.

So I would expect that either SingularValueList[m]; // AbsoluteTiming matches MatrixRank[m]; // AbsoluteTiming closely in Mma 10.1 or Wolfram has switched to another scheme for computing MatrixRank in Mma 10.1 (and not yet updated the online help).

The online Wolfram language help page for both MatrixRank and SingularValueList  currently say in their footers that they were last updated in 2007 (6.0).

@Preben Alsholm Not a coincidence, I suspect: I exchanged mail with two other people about that very example.

Anyway, it looks like a bug that's been around for some time.

@casperyc Thanks. The difference in timing that you report between Mma 10.0.x and 10.1 is interesting.

I'm unaware of any change in MKL 11.2 that would account a difference of that proportion. And also your i7 940X doesn't have AVX extensions. So now my best guess is that Mma 10.1 might be computing the rank of a float Matrix differently than it did before. Ever since I can recall all of Matlab, Maple, and Mma have computed such a rank by examing how many of the singular values are proportionally close enough to the largest singular value. That is very likely why, for example, the performance of double (machine) precision float matrix rank computation is essentially identical at almost all sizes up to at least n=8000 in Maple 2015, Mma 10.0, and the Matlab of the same year, as far as I know. Those are very likely all just using the same MKL function, in the same way, to compute all singular values and compare.

Now, some recent LAPACK versions have included some new functions for QR decomposition, and these may be now appearing accelerated in MKL 11.2. Those may also be rank-revealing and (hopefully) more robust than earlier QR implementations. (There is a reason why Maple's LinearAlgebra:-LeastSquares offers both SVD and QR methods. The QR approach -- historically -- traded off robustness for speed. So any new and robust and rank-revealing QR function would be quite appealing.)

Once I get my hands on Mma 10.1 I'll time their SingularValues command against their Rank command, and see how that pair compare in 10.1 versus how that pair compared in previous releases. It may take a little while since Wolfram don't have a good track record with making new releases available for download in a timely way to all customers. (This is not the first new release for which I've had to wait, for no good reason...)

@Preben Alsholm A bug report has been submitted.

The following basic example is interesting.

restart;
eq:=.4*eta-0.8e-1+(.1*(.4*eta+1))*(2-x)=0:
isolate(eq,x);

Conversion to rational is one way around the the above example's problem. Another (for that example, at least) is isolate(normal(eq),x).