@Carl Love The member has made little effort to figure out the Maple equivalents for what appears to be Matlab code.

For example add(x, x=spin) would add all the elements of Matrix spin, instead of his sum(sum(spin)). It's unclear to me whether exp(-DeltaE) is intended as a matrix-exponential or the elementwise operation (it's unclear that the member knows Matlab well either), especially since what seems like it ought to be an assignment to p doesn't use that result later. And if rand(N)<trans is supposed to be evaluated as boolean to 0 or 1 (false or true) then how to compare rand(N) to 0.1 numerically even it it were made proper syntax for a RNG call within a call to `if`? And what is the initial value of trans?

It's a bit of a shambles.

For longer commentary I use Shift-Enter to get a new line (but still within the same Execuction Group) and then Ctrl-t to toggle to text mode.

That allows me to put commentary (in black by default) either above or below the code. And it even allows me to put typeset non-executable 2D Math inlined into the text paragraphs.

acer

@Doug Meade In 2D Math mode, the keystrokes would be (ignoring my whitespace),

| | V | | <ctl><shift><_>2

By <ctl><shift><_> I mean simultaneously pressing Control-Shift-underscore.

The point is that the norm `p`=2 has to be in a subscript. And it cannot be an atomic double-underscore subscript.

That works for me in Maple 2016, and the result  for V=Vector(1,2,3]) is sqrt(14).

Is this parsing rule available for modification by the Typesetting:-RuleAssistant? I didn't see it there. (...and I think I may have a handle on how to list off all that Assistant's candidates, but as mentioned I am not yet seeing it there).

It's not clear whether you have some initial-value problem to solve numerically, or have been given the specific task of writing your own code for that (say, as coursework or homework).

If you do not need to write your own scheme then simply use the dsolve command with the numeric option (and do not force a classical method or a fixed stepsize, without justificsation, as the solver can do often do better than that automatically). Start by reading the help page for topic dsolve,numeric .

acer

@Kitonum If you change that k4 assignment to instead  use h rather than h/2, so as to be  k4:=f(t[n]+h,y[n]+h*k3)  then (if Digits=15 say) you'll get results which concur with the following stock command's results:

restart;

K:=dsolve({diff(y(t),t)=sin(t),y(0)=1},numeric,method=classical[rk4],
           stepsize=0.1,output=Array([seq(0..5,0.1)])):

convert(K[2,1],listlist);

 [[0., 1.], [0.1, 1.00499583489549], [0.2, 1.01993342285110], 
  [0.3, 1.04466351242567], [0.4, 1.07893900873887], [0.5, 1.12241744236150], 
  [0.6, 1.17466439115686], [0.7, 1.23515782088314], [0.8, 1.30329330118699], 
  [0.9, 1.37839004487179], [1.0, 1.45969771009834], [1.1, 1.54640389755243], 
  [1.2, 1.63764226767027], [1.3, 1.73250119681705], [1.4, 1.83003288592892], 
  [1.5, 1.92926283060797], [1.6, 2.02919955804802], [1.7, 2.12884453350318], 
  [1.8, 2.22720213731696], [1.9, 2.32328961282474], [2.0, 2.41614688573355], 
  [2.1, 2.50484615686701], [2.2, 2.58850117242805], [2.3, 2.66627607915385], 
  [2.4, 2.73739377588537], [2.5, 2.80114367810526], [2.6, 2.85688881786345], 
  [2.7, 2.90407220815036], [2.8, 2.94222240812701], [2.9, 2.97095823360601], 
  [3.0, 2.98999256571798], [3.1, 2.99913521970836], [3.2, 2.99829484520064], 
  [3.3, 2.98747983893912], [3.4, 2.96679826089140], [3.5, 2.93645675454889], 
  [3.6, 2.89675848221342], [3.7, 2.84810009589965], [3.8, 2.79096777411931], 
  [3.9, 2.72593236414619], [4.0, 2.65364367829889], [4.1, 2.57482400123093], 
  [4.2, 2.49026087310127], [4.3, 2.40079922073331], [4.4, 2.30733291538543], 
  [4.5, 2.21079584148481], [4.6, 2.11215256556296], [4.7, 2.01238869862574], 
  [4.8, 1.91250104825405], [4.9, 1.81348765883193], [5.0, 1.71633783941702]]

@Wtolrud I don't understand what keystrokes you think got made there.

In 2D Math entry mode two ways to get such a (typeset) pretty-printed Norm call as input include: using the palettes, or using command-completion templates.

Are you referring to command-completion?

If so then see the following help topics,

  worksheet,expression,completecommand

  Typesetting,RuleAssistant

I don't know of a nice entry-level command for getting all the known (system) 2D Math completion rules, in such a way that you could manipulate it programmatically. The RuleAssistant offers access to them via drop-menus.

acer

@Carl Love The stock Matrix command can flatten too, if the Matrix entries in lists of lists.

The angle-bracket constructors won't allow application of a new datatype. Sure, he could have put datatype=float on each of the entry Matrices made by `helper2`, say. (We don't know for sure whether was desired or allowed.)

IMO simplest solution is build the Matrix B using lists and seq instead of the initializer. Using the Flatten command on the Matrix of Matrices entails building the Matrix of Matrices (in the imperfect fashion) and then repairing it with the custom Flatten procedure. But the Matrix command can build the final result immediately if called differently, with specified datatype, without need for fix up.

@Carl Love I just wondered whether it made a difference, in the case that it was to be re-used. Perhaps not relevant here.

@Carl Love Can that `All` be a local of an appliable module, so as to be created in advance and re-used?

@Mac Dude You can mark an execution group with a bookmark, and then elsewhere in the sheet you can create one or more hyperlinks to it.

For example, in this attachment if you left-click on the text word link then it will expand and jump to the bookmarked section. bkmrk.mw

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