@William Simpson You execute the command in Maple itself.

libname; 

Don't forget the semicolon.

@adrian5213 

Why do you try it as,

Do(C = table([HD]));

instead of, (say, if HD's value is a list),

C := table( Do(HD) ));

or

C := table( HD );

?

Your previous posts showed confusion on your part about regular Maple assignments and programming versus getting values in and out of Embedded Components. So why post this new question with all the calls to DocumentTools:-Do without uploading a sheet?

I have a suggestion for you: stop using DocumentTools:-Do, and use only DocumentTools:-SetProperty for setting qualities of your components, and only DocumentTools:-Getproperty for extracting them, and regular Maple programming for all other assignments and statements.

Even better, first make your program work completely without embedded components, and only then try to put the steps into the components. And then upload a sheet so that we can see what's really going on.

@Joe Riel While those inert functions are useful, we'll have to see whether the OP is content with a gray dot, as opposed to nothing or a space.

@Joe Riel 

[edited] You could also throw in spaces between elements of the typeset sequence. And you could use some other infix neutral operator if you prefer to not use &* (which might expand...).

Download matrixform.mw

@Bendesarts F is called twice per textplot (once directly and once inside S), for each value of i in the seq. So to avoid recomputation I thought I'd make it a little more efficient by having it remember the results. That's what option remember does. And the option system allows the stored results to be reclaimed upon garbage collection. You won't notice such effects for such small lists.

I wasn't happy (originally) with how close the textplots are above the extreme values (when place just "above" or "below"). The textplots were a little too close to the associated point. So I used procedure S to put in a little offset for correction. The offset gets scaled by the total height from low point to high point in theta4. If you multiply all the theta4 data by 1000 or 1/1000 say then the small offset correcttion should still work.

The overall effect seems to be quite legible.

@Ronan Ah, I see now. If you have interface(typesetting=extended)  set, which is also an option under Tools->Options from the menubar, then the entries of M do not get displayed with the evaluated entries upon printing. That affects just the display of that single example in my sheet which you noticed. It seems not restricted to Maple 18. The extracted entries are as expected, however.

I will submit a report, so that someone can decide whether it's a bug. (IMO it is a bug.)

@Doug Meade  The gridlines are an artefact of an old and reported mapleprimes bug. I try to remember to add the option gridlines=false for 2D plots in sheets to inline here.... until I remember that the rendering is awful anyway, and then export/upload as gif.

@Carl Love We can compare the results from computing the Lyapunov explonents with the bifurcation diagram (observing behavior when the estimated L.E. are less than, equal to, or greater than zero).

A cobweb plot provides another way to observe the emergent chaotic behavior. Using Explore we can see how the cycling vs chaotic behavior switches, for various values of paramater a (which I renamed r). The changes in behavior will coincide with features in the bifurcation diagram (or the Lyapunov exponent plot).

I put Carl's LyapunovExponent procedure in the Startup Code region of this attached worksheet.

Download biflyap.mw

There is also a mandelbroid fractal to associate with this (analogous to how some of the usual Mandelbrot fractal's bulbs' meeting points -- along the x-axis -- can be lined up with some features of the logistic map's bifurcation diagram, under a certain mapping). Perhaps IterativeMaps:-Escape could be used.

I wonder how else the bifurcation diagram and the L.E. plot above could be combined, for visual effect. A 3D plot? With the image on a surface or bottom plane?

@Ronan You might possibly be mixing up input and output, between what I wrote and what you mean now, with that followup comment. I was talking only about output, in my Answer.

I never use typeset 2D Input except when diagnosing/fixing other's problems or editing other's code. But I could believe that if you entered a new Matrix using the Matrix palette, where you typed in the a,2*a, etc, then that's how the typeset 2D Input would look.

You can use the green up-arrow in the editor here to upload a Worksheet or Document. If you have an apparent counter-example to what I wrote then I'd be interested to see how it was constructed.

Quite often the lprint command can reveal what is what, and there are other more powerful tools available for poking about.

@Christopher2222 No, not unless you purchase the more expensive licensing (think of Maple's EMP, say). There were a few posts on the wolfram community site when this new productization model appeared with 10.x.x, in which a few people grumbled. For example some people complained that they were not properly informed in advance of the new licensing model, and in consequence paid more than they ought to. I see it as just another way in which WRI tries to nickel&dime its customers.

There are a few emergency-style rushed updates of the form 10.x.N where N>0, but they are few and don't seem to contain a great many fixes.

There is another problem with this new productization model of Mma, apart from the licensing fees. As far as I can see the 10.x.0 updates often have several serious regression bugs in them. So it is much harder, if not impossible, to get reasonable bug fixes for some parts of the product while at the same time avoiding new breakages that accompany the updates. This is a seriously scary pricing model, for a product that may always require regular and ongoing license updating (eg, annual cost).

The burden must be on you to first say how you will accept the distribution of the points. You have used the term "random point" and it is only sensible if you cast that in a mathematically precise way.

acer

@Carl Love For the OP to ask how to use method=lsode in the same message that asks what numerical algorithm it uses demonstrates that the OP should not be using this method. Better would be to try default nonstiff/stiff methods, or specify none until such time as there is a justification to change methods. With no rationale to specify lsode it makes little to no sense for the OP to be getting bogged down in its subtleties. (Your first reply had some of this gist, but I think the OP really needs to think harder about it, or to state the motivation.)

Are you sure that the whole "a+b = 4+5 = 9" business is not more you're own (possibly mistaken) interpretation of what might be a simpler demand? That interpretation of the demand to "display the results between calculations" is extremely difficult to get exactly right in all situations. I consider it quite unlikely that most instructors would even realize the full depth of the difficulties involved there.

I mean, perhaps the instructor would be satisfied if you simply terminated all assignments with semicolons, and made sure always to assign intermediary computations to (temp) names, prior to passing them into further commands?

acer

@Carl Love That won't work in a variety of different situations, not least of which being the case of a call to a command that expects a numeric argument rather than a uneval-quoted name.

For example,

Display:= proc(e::algebraic)
     local r:= eval(e);
     print(nprintf("%a = %Q", e, subsindets(e, name, n-> nprintf("%Q", eval(n)))) = r);
     r;
end proc:

n := 4:
Display( series(sin(x), x, 'n') ):
Error, invalid input: series expects its 3rd argument, n, to be of type {infinity, nonnegint}, but received n

However the above example would work if the entire argument passed to `Display` were uneval-quoted.

n := 4:
Display( 'series(sin(x), x, n)' ):

                                                 1  3    / 5\
   series(sin(x),x,n) = series(sin(x),x,4) = x - - x  + O\x /
                                                 6           

With that in mind, it seems simpler to define that `e` parameter of `Display` as being of type uneval. That way the extra quoting is left out of it. Eg,

restart;

Display:= proc(e::uneval)
     local pre := subsindets(e,uneval(name),eval,1);
     local r := eval(pre);
     if indets(pre,And(name,satisfies(u->u<>eval(u))))={} then
       print(r);
     else
       print(nprintf("%a = %Q", pre,
                     subsindets(pre, name, n-> nprintf("%Q", eval(n))))
             = r);
     end if;
     r;
end proc:

n := 4:
Display( series(sin(x), x, n) ):

                                                 1  3    / 5\
   series(sin(x),x,n) = series(sin(x),x,4) = x - - x  + O\x /
                                                 6           

(a,b) := (3,4):
c := Display( a + b ):

                         a+b = 3+4 = 7

Display( sin(3.4) * cos(3.4) ):

                          0.2470566755

Display( cos(3.4*n) ):

             cos(3.4*n) = cos(3.4*4) = 0.5117039925

f := tan(x):
s := t: t := u: u := v: v := w: w := x:
Display( series(f, s, n) ):

                                              1  3    / 5\
     series(f,s,n) = series(tan(x),x,4) = x + - x  + O\x /
                                              3   
        
count := 0:
g := proc(z) global count; count:=count+1; cos(z); end proc:
Display( g(3.4*n) ):

               g(3.4*n) = g(3.4*4) = 0.5117039925

count; # should return 1

                               1

Of course it's almost impossible to make this kind of thing perfect. And automatic simplification gets in the way too.

@jtorre Yes, because sin(i) returns sin(i) for unassigned `i`. Please read all the answers carefully.

Your original example was effectively computing this:

nops(L(i));
                                          1

sum(%, i=1..2 );
                                          2