Which version of Maple?

You can set up a PlotComponent from the Embedded Components palette, and then use SetProperty(...,refresh) to update it while your looping code is running.

There are even easier ways, in Maple 2015, which is why I ask about the version.

acer

An ellpise can also look nicer than a rectangle, for longer labels.

restart:

quad2ellipse := proc(P::specfunc(anything,:-PLOT))
  subsindets(P,
             And(specfunc(':-POLYGONS'),
                 satisfies(p->nops(p)>0
                           and op(1,p)::[[numeric,numeric],[numeric,numeric],
                                         [numeric,numeric],[numeric,numeric]])),
             proc(p) local t,r;
               (t,r):=selectremove(type,[op(p)],list(list(numeric)));
               ':-POLYGONS'(seq(op(plottools:-ellipse([(op([1,1],pp)+op([3,1],pp))/2,
                                    (op([1,2],pp)+op([2,2],pp))/2],
                                   1.3*abs(op([1,1],pp)-op([3,1],pp))/2,
                                   1.2*abs(op([2,2],pp)-op([1,2],pp))/2)),
                                pp in t), op(r)); end proc);
end proc:

with(GraphTheory):

G := Graph({{"blah","FOO"},{"bleh","FOO"},{"FOO","blah"},
            {"FOO",4444},{4444,5555},{5555,"Z"},{"Z",4444}}):
HighlightVertex(G, Vertices(G), gold):
HighlightEdges(G, G, COLOR(RGB,0.2,0.2,0.7)):

P:=DrawGraph(G): P;
quad2ellipse(P);

This hack is only a good as the original rectangle to fogure out the width. And the original goes wrong for very long labels.

@Alejandro Jakubi The purpose of the comment in my code is to to describe somewhat what the code is doing, as it might differ from what others do in such cases. It's not an instruction for the world, or a description of what I expect of other people.

I am not angry at all. Indeed I am amused by your long-standing tendency to see conspiracy and ulterior motive where none exists. Which leads me to ask, in the words of Jack Burton,

https://www.youtube.com/watch?v=WLSSh6G3Bx0 

@Alejandro Jakubi It may be OK if simplify (or another command) utilizes length while measuring the size of an expression. That depends on the structure of the expression. But I do not believe that length alone is a sensible measure of expression size for all purposes.

Suppose that one wishes to simplify a non-constant expression for the purpose of reducing the time for evaluating at a point. In that case it would not be sensible to rely on the following, as the length of the names ought not matter. Consider the following example, for which the cost of evaluation ought not (within reasonable bounds) depend on the length of the names,

length(aaaaaa+bbbbbbbbbb);
                                      23

length(a+b);
                                       9

But `simplify/size/length` does a more sensible job here, returning the same value (9, if it matters) for both of those two expressions. And MmaTranslator:-Mma:-LeafCount also returns the same value (3, if it matters) for both those expressions.

It's not difficult to come up with other problematic examples too. For example a multivariable expression which might factor in two different ways (according to choice of variable). It doesn't seem very sensible and useful for the purpose of evaluation cost (at least) if one factorization is chosen by virtue of being the one which has the least instances of the much longer name. More sensible and useful for the purpose of evaluation cost reduction would be the choice which minimizes operations regardless of name lengths.

Also, the worksheet I posted made use of simplify(...,size) and so it makes sense to use the same metric to gauge the relative success of that operation. I often see people use raw length calls in order to gauge the success of their calls to simplify(...,size), and that is not as sensible as would be using the metric that simplify(...,size) itself uses. The person who posted this Question did that very thing, which is partly why I added the comment.

You often read too much into my comments, or misinterpret them.

Now, if the purpose is to simplify so that the expression takes less space on disk, or as .m format in a .mla archive, then it could well be a whole other ballgame. I wrote my response worksheet with an eye toward evaluation cost,and if that it not what the OP intended then I hope it'll be clarified as followup.

By the way, another interesting metric can be had using the codegen[cost] command, although unfortunately it is difficult to make programmatic use of the result. What's appealing there is that its result includes the separate detail of the number of function costs. It might be nice to have some similar command which could return a list of the various counts, to which a custom weighting could be applied after the fact.

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...)