@Doug Meade In Maple 2015 the 2D rendering of names  epsilon , `ε` , varepsilon , and `ϵ` were changed, as documented in the Compatibility notes to that release.

It makes matters a bit more confusing that (at the time that I write this) the MapleNet used in the Online Help displays them in the old way for the online version of that page -- and so is incorrect.

In addition to the compatibility notes, the name varepsilon gets typeset the same way as does `ϵ` in Maple 2015. If that is documented in the What's New then I've missed it.

There is some improvement in 2015.2 over 18.02, in the sense that rendering of typeset epsilon and `ε` have become consistent.

I'll attach some screenshots, where I get them rendered as 2D Output as well as insert them from the Greek palette.

Maple 18.02 at 150% zoom, on 64bit Windows 7, where the discrepency between epsilon and `ε` is clear.

Maple 2015.2 at 150% zoom, on 64bit Windows 7, shows that discrepency removed, albeit at the cost of incompatibility.

The above are both at 150% zoom. But at 100% zoom the varepsilon looks too much like an italic "e" to me in my old Linux SuSE 10.04. Here is is on my Windows 7, which is acceptable but not great:

And here it is on my (very old) 64bit Linux SuSE 10.04, with the varepsilon rendering too much like an "e" at 100% zoom.

I always use the GUI at 100% zoom, so the rendering of varepsilon is problematic to me. It may possibly be a font issue specific to my very old (officially unsupported version) though.

The above are all screenshots. The images are not all the same size as I've used different screen grabbers across platforms.

@iman The name `1` is used instead of the integer 1 in several places.

That occurs in the assignment to bcs2. It also happens several times in the list used for the approxsoln option passed to dsolve.

If I delete these instances of `1` and replace by the integer 1 then the dsolve calls return a new error message to the effect that 14 boundary conditions are expected but only 12 received.

You might consider switching to 1D Maple Notation for input, instead of 2D Math input., if you are having these kinds of problems with your authored code.

On the 7th line, where you assign values to some parameters, there is s=0.1 which is an equation not an assignment. You likely intended that as s:=0.1 instead.

I don't know the code for shoot, but it may not be possible to use the variable  (ie. gamma) if you don't first declare it as a local at the top-level, since Maple thinks that  (ie. gamma) is a special constant. I suggest that you simply use another name instead.

acer

I may have to recant.

The reason why I originally expected neither method to work was that (as Carl mentions) names in the :: type do not evaluate. That's related to why we don't uneval quote Matrix when using x::Matrix(square) , as it will not call the Matrix constructor. That contrasts with checking the type by calling type(M, 'Matrix'(square)) say.

But a formal parameter of a procedure is, effectively, used in the procedure like a constant rather than a (variable) name whose value may vary. (Perhaps this is what Christian's comments are about.) I'm referring here to parameter dim of createModule1.

So it may be that the different behaviour of createModule1 and the original createModule2 is technically correct.

But at least I got to report that other bug with the invalid substituion...

subs(y=(2,2), proc() :-y; end proc); # I'd like to see an error message here
                            proc() :-2, 2 end proc

> dismantle(%);

PROC(11)
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
s=0x7fb5a5b203f0, unexpected EXPSEQ member of MEMBER
Error, (in dismantle/dump) object at address is invalid

Thanks to John for the invigorating examples.

@Carl Love The version with dim declared local (as vv had done) is better, by way of being safer.

The slightly modified createModule2 example below, in which the global :-dim is utilized within the constructed module export det, will go wrong if dim does not scope out to a local for that subs call being made inside det.

The local dim declaration could be part of either createModule2 (as vv had it, and as I had it in my unapply workaround above) or the constructed anonymous module.

If you run the code below, without dim declared local within createModule2 or the constructed module, then you should be able to see what I mean.

restart:

dim:=13.5:

with(LinearAlgebra):

createModule1 := proc(dim::posint)
    module()
        export det;
        det := ((x::Matrix(1..dim,1..dim)) -> :-dim*Determinant(x));
    end module
end proc:

createModule1(       2 ):-det(IdentityMatrix(2));

                              13.5

createModule2:= proc(A::Matrix(square))
uses LA= LinearAlgebra;
     module()
     local dim;
     export 
          det:= subs('dim'= LA:-Dimension(A), (x::Matrix(dim))-> :-dim*LA:-Determinant(x))
     ; 
     end module
end proc:

eval(createModule2(Matrix(2)):-det);

          x::(Matrix(2, 2)) -> :-dim LinearAlgebra:-Determinant(x)

createModule2(Matrix(2)):-det(IdentityMatrix(2));
                              13.5

And I've submitted a separate report that the following crashes the kernel. An error message about invalid substitution would be gentler.

p:=subs(y=(2,2),proc() :-y; end proc);
                          p := proc() :-2, 2 end proc

p();
Execution stopped: Stack limit reached.

@John Fredsted That the second one does not work.

I have submitted a bug report.

@John Fredsted I notice that in Maple 9.03, 9.50, and 10.03 the first way does not work either (producing the same error), but the first works in versions 11.00 onwards.

Interesting question. I'm a tiny little surprised that either work. While we await the light, here is a workaround for the LOCAL `dim` case,

createModule2 := proc(A::Matrix(square))
    local dim, x;
    dim := LinearAlgebra:-RowDimension(A);
    module()
        export det;
        #det := unapply('LinearAlgebra:-Determinant'(x),x::'Matrix'(dim,dim));
        det := codegen[makeproc]('LinearAlgebra:-Determinant'(x),[x::'Matrix'(dim,dim)]);
    end module
end proc:

I mention `makeproc` as well as `unapply`, because the former can be more powerful, I wasn't sure how complicated your constructed module's proc might be, and to what degree this is a toy example.

acer

Your followup question is also about a topic that is very involved. Maple's type system is not hierarchical. For a given expression a variety of type-checks are done, results being encoded numerically, and then recursive lookup done to figure out what items belong in the menu. In order to be more efficient this makes use of tree structures, records, and recursion. Done naively the menu construction could be very expensive, and one consequence of the current implementation is that the whole process is rather opaque.

I'll dig some more and if I find a reasonably convenient way to query and display what (I think that) you're asking I'll follow up. But I wouldn't hold your breath..., sorry.

On the off chance that what you really want to do is figure out how to customize the context-menus so that your favoured items show more often, then that is actually quite straightforward. You could read the various ContextMenu help pages that cover it. I've made a few posts that utilize this functionality in the past, see 1, 2, 3, 4.

I can also mention that you can programmatically obtain a representation of the context-menu items that would appear for some given expression. For the expression a=0 , where a is the unassigned name, one way to obtain a terse representation of the menu items would be,

  ContextMenu:-Test:-GetGeneratedMenu( a=0 );

while a more detailed and more convoluted representation could be obtained using the command,

  ContextMenu( a=0, true );

@Markiyan Hirnyk Yes, I am quite aware that was the original question. My answer relates to how the context-menu can be augmented with some additional commands (which can also induce some replacement) and I explicitly stated as much.

The reason I gave the answer is that it is the kind of question that new users ask, and it may still be of some value to the Asker or others.

The precise answer to the original question is no, it cannot be done.

Apart from the sheer magnitude of the task there are considerable difficulties in the way of a user trying to achieve such an enhancement programmatically. One obstacle is that various commands have alternate calling sequences, the legal set of which are not programmatically available. While many newer commands use the builtin parameter-processing for proc definition there are many which do not -- the logic of what is acceptable as command arguments cannot itself be picked apart and massaged into a scheme for automatically generating all valid menu actions. This is also true of many command which do use such parameter-processing. A very hard part woudl lie in programmatically generating the menu items for all calls where additional arguments are legal, or required. This is on top of the notion that such a complete menu system would be so large that using it would likely be impractical.

There is much more involved in the general topic of the question asked here. For one thing, it is important to note that the ability to write arbitrary programs in the Maple language means that there will always be a much broader set of things that can be done with custom programming than can ever be done in practice with any finite set of context-menu items. Interactive Maple use via context-menus may be great for students learning math but it can never match the power of a programming language for more general computation. Hence I tailored an answer that may be useful to students.

@tomleslie Since you now indicate your initial response to my Answer wasn't directly related to my Answer (or its statements about calling the print command from within Document Blocks) then I've changed your Comment into an Answer.

When a Document Block is not in "expanded" state then it consists of a pair of Execution Groups. The output of the first is supressed and the input of the second is supressed from display. The output of the first is used as input for the second, behind the scenes in the GUI when the Block is "collapsed" = not "expanded". This scheme causes all normally printed output to be queued (as the redirected material) and only printed altogether once the first Execution Group (containing the user's command) finishes computing.

If you execute the code in either of the two collapsed Document Blocks in the attached Document you should see that the printed results for either collapsed Block are displayed in two clumps. The individual printed statements do not get printed one at a time, asynchronously. The same goes for lprint, printf, and userinfo statements.

doubters.mw

If you were to expand either one of the two Document Blocks (select with mouse, menubar "View" submenu) then you'd see a pair of Execution Groups for each, with red prompts. If you were to execute only the first of the pair of Execution Groups in an expanded Document Block then the results would display asynchronously, just as Worksheet users expect.  There is an "output redirected" comment, between the Groups, if an entire expanded Block is executed together, say using the menubar's `!!!` icon.

This is just one reason why I don't use Documents, and stick to Worksheets.

I see an expectedly close result in Maple 15.01, but not in Maple 16.00 onwards.

It may be possible to work around the issue by assigning UseHardwareFloats:=false and retaining Digits=10, without having to incur even more extra cost of higher that default working precision. (That still won't be as fast as hardware double precision at the key steps internally, of course.)

restart:                                      
with(Statistics):                             

r := RandomVariable(NegativeBinomial(3, 0.1)):

Mean(Sample(r, 10000)); Mean(r): evalf(%);    
                               101.792300000000

                                  27.00000000

UseHardwareFloats:=false:
Mean(Sample(r, 10000)); Mean(r): evalf(%);

                                  27.02560000

                                  27.00000000

@Mac Dude FYI, I included another kind of example (affecting BesselY, BesselK and perhaps AiryAi, AiryBi but not others it seems):

restart;                   
evalf( BesselY(0, 2/3*x) );
                          BesselY(0., 0.6666666667 x)

restart;                   
UseHardwareFloats:=true:   
evalf( BesselY(0, 2/3*x) );
Error, (in evalf/BesselY) cannot handle unevaluated name `x` in evalhf

kernelopts(version);
           Maple 2015.2, X86 64 LINUX, Nov 13 2015, Build ID 1087698