@Christopher2222 You make several mistakes and it's a shame you feel compelled to keep doing this in Comments to my Answer.

For example, the DirectSearch v2 zip file (now) contains a third file, which is in the new .help format required by recent Maple versions. (It helps new users to have it already converted, else they need to figure out how to do it themselves, manually).

Next, the method of augmenting libname allows the commands to be found accessed from the .mla, but does not allow the help pages to work (in versions back to, umm, Maple 14 or so if I recall). This is remedied by either using an initialization file to set libname, or by going with the other approaches I described.

My Answer already covered the scenarios you now describe, but without the mistakes. Moreover it contains the better method, not mentioned in the readme.txt of the DirectSearch v2 .zip file: put the files into a toolbox folder.

I think that the DirectSearch .zip file should get augmented with a self-extracting archive which when opened in the GUI launches installation Maplets that allow installing to either a private (optionally version-specific) toolbox folder or a toolbox folder inside the Maple base location. This kind of thing can be created using the InstallerBuilder. It should be done by someone at Maplesoft who knows all the ins and outs.

The current title of this post is Document vs worksheet mode but the points raised are about (plaintext) 1D Maple Notation vs 2D Math Notation (typeset input).

As Egdardo has mentioned, it is possible to use either 1D or 2D entry modes within a Worksheet (which is comprised of execution groups), and even within a Document it is possible to insert an execution group (within which either 1D or 2D notation is possible).

And indeed there are two separate settings, for control of default behaviour. From the main menu, Tools->Option->Interface has the setting for "Default format for new worksheets" which can be set to either Document or Worksheet. And from the main menu, Tools->Options->Display has the setting for the default "Input display" which can be set to either (1D) Maple Notation or 2-D Math Notation.

Technically, the terms Document mode and Worksheet mode are more about how the sheet behaves: how one navigates within it with keystrokes and execution, how input and output are managed, how menu items such as "Insert-Paragraph" behave, how the results of applying right-click context-menu actions will appear and behave under re-executuion, etc.

The submitter also uses the phrase, "the call and response method", which ought to be explained. Is that a reference to the work style of entering commands explictly (in either 1D or 2D), in contrast to using context-menu actions? If so then it should be noted that this choice is also possible in either Worksheet or Document. Both allow for explicit statements of code entered by key-press or palette.

In short, there are more than just two possible styles of interaction and workflow. I suggest that you have three principle chocies to make: 1D vs 2D, Worksheet vs Document, and explicit commands exclusively vs context-menu actions.

A key detail here is the level of arbitrary programming expected from the student. Will Maple be used primarily as a tool for interactive use of canned commands along with typeset exposition and report authoring, or as a vehicle for involved programming related to their discipline? Or somewhere in between?

There will always be a balance between ease-of-use and power.

In my 20 years of experience observing many people new to Maple, the relatively shortest path (ease of use) to results with the broadest kind of result (power) involves using the 1D Maple Notation in a Worksheet without context-menu computation. In the particular case of computations for physics then recent advances make 2D Notation in a Worksheet a very attractive proposition.

There are some additional challenges to using 2D Notation (from subtlety, through frustration, down to bugs). But it's the first choice of the three I listed which I'd suggest switching on. The students will encounter more ambiguous input, work harder to edit and copy&paste and format code, execute the wrong code unwittingly due to superflous/omitted implicit multiplication, run afoul of mistakenly pasting in 1D Notation code into a 2D input area an hitting their different syntax interpretations, need to learn 1D anyway, etc. But it will look pretty, and may well be more legible and easily comprehensible to them. If their discipline is physics then the advantages of 2D typesetting in Maple would be considerable.

With 2D input mode enabled more items from the palettes will be enabled for them. I suggest that you encourage the students -- if only while learning -- in the habit of obtaining nicely formatted 2D input by using command-completion instead of the palettes. One reason for that is that command-completion fosters learning of the 1D command names, which they will need to do in any case. Another reason is that it teaches them what is actually going on. When they need to adjust some command call to something which does not typeset the same then the situation will be easier to comprehend. For example, the student who can obtain a prettyprinted integral for the call evalf(Int(f(x),x=0..1)) via command-completion will have little trouble entering the non-prettyprinted call evalf(Int(f(x),x=0..1, method=_d01ajc)). But the student who only knows how to enter integrals from the palette entry will have more trouble figuring it out.

Switching from Worksheet to Document will involve a great deal more frustration and work in learning to navigate and edit, program, debug, and wil likely involve considerably more enquiries to you for assistance.

Use of context-menu actions (eg, right-click menus) will hinder your students who are studying beyond 1st year math, obscure (from their colleagues, you, and possibly themselves) the nature of their coding, slow them down if they eventually need more than the mechanism provides canned, and delay the continued need to learn how Maple actually computes things and works as a programming language.

acer

@MortenZdk The problem you are seeing now is known as premature evaluation.

Under Maple's usual evaluation rules for calling procedures, the arguments to the procedure call are evaluated up front, before the procedure body runs or sees them If any of the arguments would emit an error on its own, then that's what happens for the procedure call too.

That's what happened in your first attempt to plot using the call plot(Prev(p), p=0..1) where the plot command never gets to do any work because the error occurs up front during evaluation of the argument Prev(p).

There are a few Maple commands which have so-called special evaluation rules, to delay evaluation of the arguments. But plot is not one of these. There are several ways to work around this issue. One way is to use the so-called operator form in the calling sequence. Another way is to delay the argument evaluation using uneval quotes. Another way is to make the procedure (used in the argument) itself return unevaluated whenever its own passed argument is not numeric.

restart;

with(Student[Statistics]):
X:=NormalRandomVariable(0,1):
Probability(X <= 0.6);
                              0.725746882249926

Prev:=p->fsolve(Probability(X<=x)=p, x):

# Emits an error, because `p` does not yet have a numeric value...
Prev(p);
Error, (in fsolve) p is in the equation, and is not solved for

# ...hence by usual evaluation rules this does too.
plot(Prev(p), p=0..1, size=[300,100], adaptive=false, numpoints=150);
Error, (in fsolve) p is in the equation, and is not solved for

# This is often known as the "operator form" of the calling sequence.
plot(Prev, 0..1, size=[300,100], adaptive=false, numpoints=150): #works

# Next we use so-called uneval quotes to delay the evaluation.
plot('Prev'(p), p=0..1, size=[300,100], adaptive=false, numpoints=150): #works

plot('Prev(p)', p=0..1, size=[300,100], adaptive=false, numpoints=150): #works

Prevalt:=proc(p)
  if not type(p,numeric) then return 'procname'(args); end if;
  fsolve(Probability(X<=x)=p, x);
end proc:
# Returns unevaluated...
Prevalt(p);
                                 Prevalt(p)
# ...hence this works.
plot(Prevalt(p), p=0..1, size=[300,100], adaptive=false, numpoints=150): #works

Having covered all that stuff, we can also examine performance. It turns out that the Statistics:-Quantile command is (generally) more efficient for this inversion computation than is fsolve (which has less special knowledge of the computation's nature). Timing is a tricky business, but the following may give a rough idea.

CodeTools:-Usage(
  plot(Prev, 0..1, size=[300,100], adaptive=false, numpoints=150)
):
memory used=58.16MiB, alloc change=32.00MiB, cpu time=3.03s, real time=2.95s, gc time=312.00ms

Quantile(X,p); # symbolic solution
                                                  (1/2)
                      RootOf(-erf(_Z) - 1 + 2 p) 2     

# This next simply plots the above explicit expression for the solution.
CodeTools:-Usage(
  plot(Quantile(X,p), p=0..1, size=[300,100], adaptive=false, numpoints=150)
):
memory used=20.26MiB, alloc change=0 bytes, cpu time=639.00ms, real time=641.00ms, gc time=0ns

CodeTools:-Usage(
  plot('Quantile(X,p)', p=0..1, size=[300,100], adaptive=false, numpoints=150)
):
memory used=4.95MiB, alloc change=0 bytes, cpu time=188.00ms, real time=188.00ms, gc time=0ns

@Carl Love modules have last-name-eval, so a name to which a module has been assigned is of type algebraic.

But a module itself is not of type algebraic. And (for one reason or another) Statistics:-Mean is expecting a first required argument of type algebraic (or of type array, or list, or rtable, or DataFrame, or DataSeries).

Some other Statistics commands have the same issue. I suppose it's an oversight (but I could be wrong). I wonder whether it'd be workable to adjust the commands to accept the right kind of module, or to reimplement the Distribution modules as (newer) objects with their own set of static exports.

@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