@Fabio92

I was wrong above: An implicit option can be used with numeric dsolve, but it means something completely different than when it's used with symbolic dsolve, which led to my confusion. It's described on page ?dsolve,numeric,IVP. It says that it's only used with IVPs. Since you have a DAE, it's likely incompatible.

@Annonymouse You should thank me by selecting this Answer as the Best Answer to your Question (use the trophy icon in the upper right corner of the main post of the Answer) and by going back and doing likewise for all of your previous Questions over the years for which I gave the best answer. And for any Answers to anyone else's Questions that you appreciate, you should click on the Thumbs Up icon. It deeply offends me when people neglect these simple courtesies that are even easier than typing "Thanks" , so please do it ASAP.

To retrofit the code above to your version of Maple, change the last line to

plots:-matrixplot(Matrix((n,m), curry(Sols3, H, F)), heights= histogram);

@mmcdara Thanks for the thoroughly referenced information! It confirms what I had already guessed about the constant coefficients. And I guess that a likely next step after forming a symbolic likelihood function is to take the derivative of its logarithm, which would cause any positive constant coefficient to disappear.

Returning to the original Question, I see now that the normalize option to Likelihood determines whether or not to include those constants, the default being not to include them.

@Joe Riel

Joe, I long ago read that recommendation at ?||. The problem with that recommendation is that no reason is given. If the reason is efficiency related, them I'm likely to follow it. That seems unlikely since cat requires that its own name be evaluated. If the reason is that cat works better with 2D input or that it's more readable or less prone to coding errors... well, those are all garbage reasons that I refuse to accept.

So, do you know the reason?

@edahl As far as I know, most serious Maple programmers writing procedure and module codes of hundreds of lines or more maintain that code in plain text files. You can load that code into any of Maple's interfaces. There's never a need to copy-and-paste it! You either use the read command or store it in libraries (repositories of Maple code stored in a somewhat "compiled" internal format). When it's put into a library whose name is appropriately put into one's initialization file, using the code is seamless---identical to using any endogenous Maple command.

@edahl If L is a list or a set, then L[] is its underlying sequence. To use a visual metaphor, it "strips off" L's surrounding brackets or braces. It's functionally equivalent to op(L) but is more efficient due to not needing to evaluate the symbol op and not needing to construct and pass an argument sequence for op. It's also two fewer characters than op(...), and it looks much cleaner to me in the code.

Caution: L[] functions like op(L) only if L is a list or set.

So, [x,y][] is the same as (x,y), but only the former is valid as the first argument to seq because the latter would be two arguments. This only works because seq's first argument is passed unevaluated.

Some may say that op(L) is easier to read or easier to understand. Those are garbage reasons. You might as well tell a music composer that they should write their notes as A-sharp, B-flat, etc., rather than use the standard musical notation. If you want to write clean, concise Maple code, you should learn the symbols.

@edahl The text editor vim has syntax highlighting for Maple. I think Emacs does also, but I've never used it. And Maple's "Standard" GUI interface has an embedded text editor which you can insert anywhere in a worksheet by using the menu command Insert -> Code Edit Region.

The following symbols have special meaning inside procedures, and are essentially reserved words (I may have forgotten a few):

• args: the actual argument sequence with which the procedure was called
• nargs: the numbers of items in args
• thisproc: pointer to the procedure itself, useful for recursion
• procname: the name by which the procedure was invoked including any attached indices
• thismodule: pointer to the module in which the procedure is embedded, if any
• _nresults: the number of operands to the left of := when the procedure's invocation is the right-side operand
• and these, which are all adequately defined on the help page ?using_parameters: _passed, _npassed, _options, _noptions, _params, _nparams, _rest, _nrest.

@waseem You're welcome. It's also possible to embed the betas in the plot with pointers to the curves, as in your example plot. This would require looking at the plot after a first draft is plotted so that you can decide on the placement coordinates.

Why do your command prompts keep switching between "F > " and "PW > "? I've never seen switching prompts.

@edahl Since you have Maple 16, also look up ?elementwise, which explains ~.

My guess is that will also work in Maple 16:

F:= (k::posint)-> assign([m||(1..2*k)] =~ [seq([dx||i, dy||i][], i= 1..k)]):

In a comment above, I forgot to say that using || is another way to guarantee that a variable is global. Using parse is similar, but not identical: It can grant you access to a top-level local from within a procedure. All of ||, cat, nprintf, and convert(..., name) are essentially the same with respect to globalness/localness.

Here's a procedure that shows 7 variations:
 

Download Locally_produced_globals.mw

@edahl Let's first get this working in your version of Maple, then I'll explain the code that works for you. My guess is that your Maple is older than Maple 13, which would make =~ not work. Regardless, try this, which uses zip(`=`, A, B) as an older version of what's now abbreviated as A =~ B:

restart:
F:= (k::posint)-> assign(zip(`=`, [m||(1..2*k)], [seq([dx||i, dy||i][], i= 1..k)])):
F(3), m||(1..6);

Look at these help pages: ?|| and ?zip. Actually cat is more flexible than ||. You're right that ~ is very similar to map. It can also replace zip, depending on the context.

@vv Okay, yes, I see that. The answer only applies to the OP's specific context. It's what I call an ad hoc answer. And I'm not saying that ad hoc answers are a bad thing! But I think that it's clear in this case that it doesn't really address the OP's overall Question.

@vv Yes, that works for that simple example, but it is awkward. If the procedure's author needs explicit access to the bound variable (which would be true in the majority of practical cases), it requires subtle "surgery" of f and/or r to get to the variable without accidentally evaluating it. Plus, there are numerous benefits of arguments being evaluated before they are passed.

Consider what you would need to do in your example if you were writing a simple alternative to plot rather than simply passing the arguments on to plot.

@vv No: Ignoring the restart for the moment, that x is not necessarily global either. It could also be lexical, module local, module export, or top-level local. There are two ways to guarantee that a variable is global: declare it global or prefix it with unary :-.