@waseem The solution is still to use rhs(exact) rather than exact. This is needed to strip off the "y(x) =" part, which is meaningless to plot.

@acer 

There are some issues in play in this particular situation that can confound all but expert users:

• It's not immediately clear whether Typesetting:-mrow causes display to the screen via return value or via side effect.
• Indeed, it's neither a procedure nor an appliable module; it's just a mysteriously exported name of Typesetting---so, there's no code to view.
• Indeed, it isn't even documented.
• There's no associated `print/...` procedure; indeed, using it with a high printlevel reveals nothing.

I wouldn't be surprised if you, like me, have learned everything that you know about using Typesetting:-mrow by reverse engineering its expressions with lprint.

To the OP, nm: If you're faced with deciding between It's displayed via return value or It's displayed via side effect, guess the former first and investigate that possibility: assign the result to a variable and apply lprint.

You don't even have two equations. You have two expressions.

The only sensible problem akin to NonlinearFit (*footnote) that I can see to form about these two expressions is

• Find values of a[1] and b[1] that minimize the "difference" between the two expressions for all pairs (x, t) in some set S.

It remains for you to specify the set S and how "difference" is to be measured. There are some standard ways of measuring it. Let AD be the algebraic difference. Then the measured difference could be

1. the (double) integral of |AD|^2 over S (or sum, if S is countable)
2. the (double) integral of |AD| over S (or sum, if S is countable)
3. the maximum of |AD| over S
4. there are several other variations available in the package DirectSearch.

Also, it'd make it much easier if the set S were topologically compact, such as the cross product of two closed and bounded intervals, although this requirement is not absolutely essential.

So, is this what you had in mind?

(*footnote) The actual command NonlinearFit could be used if S were finite or we decided to approximate S by some finite subset of it. Otherwise, a command akin to NonlinearFit (such as Optimization:-Minimize) would be used.

@Gabriel samaila I got the ranges from the axes of the 3D plots: Nt = 0.01..0.4, Nb = 0.06..0.4, Br = 0.1..2.0, Sc = 0.1..2.0.

I haven't gotten fsolve to converge on a solution yet. I am going to try some other technique. One potential problem is that different values of those 4 hidden parameters were used for each row of Table 1. Do you think that that's possible? If that's the case, then it's hopeless to compute those values.

The paper should provide those values. It violates scientific protocol to omit them, and the paper should fail peer review for that reason alone.

@Gabriel samaila I know the default values; they've been encoded into my procedure Solve all along. I need ranges. For each of those 4 parameters, what is the minimum and maximum possible value? Or, if you can't answer that, what are the minimum and maximum reasonable, realistic, or practical values?

@Gabriel samaila Yours is a very interesting problem; I'm not getting tired of it or you at all. I don't know what you mean by "editing" sols(1): I don't see any legitimate reason to edit Maple output other than changing the formatting for display or publication purposes.

Regarding guessing the parameter values needed to construct Table 1: It's possible to do this systematically. We have the very lucky situation that the number of unknown parameters, 4, exactly equals the number of known values of C__f. So the situation is akin to numerically solving a system of 4 equations for 4 unknowns. This can be done with fsolve (that's fsolve, not dsolve) with procedure-form input (aka operator-form) where each procedure calls my Solve procedure to invoke dsolve, varying the parameters. I'm working on it now. This use of fsolve is very similar to what you'd need to do if you were backsolving to satisfy initial conditions for a shooting method.

It would help if you could tell me valid and/or reasonable ranges for the parameters Nb, Nt, Br, and Sc.

@Preben Alsholm Thank you, Preben. Since the categories DAE and IVP aren't mutally exclusive, I had some skepticism. I don't have much experience with DAEs.

Fabio, I suggest that you read the help pages ?dsolve,numeric,DAE and ?dsolve,numeric,DAE_extension. Solving DAE IVPs apparently has numerous pitfalls that solving ODE IVPs doesn't. In particular---if I've interpreted the help pages correctly---whether initial conditions are required for the purely algebraic dependent variables, and which of those variables they're required for, is highly specific to both the problem and the solution method. If that's true, then I can see that a small change in any method's code between two versions of Maple could easily change the required initial conditions.

Try removing all options other than numeric, the goal being to get through the input processor without error rather than getting an accurate or efficient solution. Once we get through that, then we'll go for accuracy, and after accuracy, we'll go for efficiency.

@waseem If you can supply the algorithm or a pointer to an online reference that I can understand, then I can code it in Maple. The material that I've been able to find has been either too broad or too engineering oriented. Please narrow it down to about five journal-length pages written with the clarity and good English grammar of a typical Wikipedia article.

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