@tomleslie It can be recovered without reexecution. I opened the Maple 7 saved worksheet in Maple 16.02 , then saved immediately without execution. That new file opened fine in my Msple 2020.1.

ps. This is all XML format stuff; nothing to do with .mws Classic worksheet format.

Opening the garbled original in my Maple 2020.1 threw a bunch of Java errors to the console, apparently related to a glitch in the 2D plot color shader and interpretation.

@Carl Love Ok, thanks. As I'm sure you're aware, that's not the same expression with which the OP started. It doesn't seem to me to be much in the spirit or making it simpler overall, to have to backtrack further to where the original Sum expression arose.

@Carl Love I considered leaving out those more complicated alternatives involving %assuming -- I thought they were zany and fun and I didn't intend them to be short as that was beside the point. I'd reach for some simpler way long before them.

But perhaps I'm missing your point, about using %assuming infix here.

@tomleslie See here.

Those are exports of the Physics:-Library subpackage. There are a few exports of that subpackage which appear to not (yet) have their own bookmarked Section and examples (or any separate help page).

note. That cited Online Help page may be slightly out-of-date, as far as revisions for Maple 2020.1 go.

@tomleslie When you issue the command with(plots) it rebinds the names connected to _pexports (aka package exports). This collection of names may be fewer in number than the exports proper.

The exports proper can all be accessed using the long-form name, eg. plots:-display3d . But the short form can only be accessed for the names that are rebound.

Here are a few reasons why an export might be removed from the package exports.
  - It is an undocumented routine intended for direct use by another package, but deemed too esoteric to be generally useful to users.
  - It is little more than a duplicate or alternate spelling of some other package export (eg. plots:-display3d, plots:-dualaxesplot)
  - It is part of the package mechanism (eg. plots:-init, plots:-_pexports itself)
  - Some developer judged it so.

The error message you cited has a slight misnomer.
    with(plots, implicitplot, display3d):
returns the error,
    Error, (in with) package plots does not export display3d
Technically it should state that display3d is not a package export of package plots. Perhaps someone thought that kind of technically correct message would be more confusing.
 

Download plots_exports.mw

@perr7 The problem is because you added the scaling=constrained option which was also (incidentally) present in Kitonum's code.

Add the style=line option, but omit the scaling=constrained option.

@Carl Love I was also trying to convey that using binomial is a decent choice even when constructing a simple procedure that would accept numeric j as argument.

For example, calling MySum(6) with your procedure calls combinat:-numbcomb six times, which each dispatch to combinat:-binomial which is binomial itself. So why not have the procedure call binomial directly and save some function calls. (Of course there is no measurable savings, for neither j nor the number of calls being very large.)

note: I did not pay attention to combining powers or measuring efficiency concerns. I still don't know what numeric values will be utilized.

@Anthrazit I have previously used a State component (hidden DataTable) where its rtable (Matrix) gets used to store other things such as a record or table.

Would it suffice for you to reference to a table that is stored in, say, the [1,1] entry of the Matrix associated with a DataTable (hidden, or not)?

That way you don't have to issue any special commands to Store/Save it to a workbook or other location prior to quitting. You just run your program that updates the table entries, and when you Close the worksheet the DataTable's Matrix is saved automagically.

The alternative, to store it manually as part of a workbook, is the kind of this that I've seen in your earlier work. (There, you programmaticallu read code from the workbook in the Start Region. You could also manually issue a command prior to closing (or press a custom Button) that saved some data to the workbook, and add additional code in the Startup to read it upon restart/re-opening. 

What have you done so far, for this homework question?

@Carl Love That's right, on all counts. But I have a hazy idea that issuing gc() explicitly may not always force a garbage-collection in modern versions the way it did some years back. I suspect that sometimes it does it when it wants to.

I suppose that, with enough calls to a Matrix initializer it might be quicker to Compile after burning the N parameter into the proc template. But that may be academic as far as optimality goes, since an in-place single procedure could walk a preformed empty Matrix and be compiled.

I left the extra procedure layer since then it had the same construction mechanism as the routine I wrote. But I was just curious about a different short way to generate the values from the indices. I have doubts that I proved much, performance-wise.

@gawati2611 Here another variant on a procedure which generates the entry value from an index pair.

Q:=proc(r::integer,c::integer,N::integer)
  local d::integer,t::integer;
  d:=c+r-2; t:=iquo(d*(d+1),2);
  `if`(d<N, t+`if`(d::even,c,r), N*(2*(d+1)-N)-t+1-`if`(d::even,r,c));
end proc:


# For example, second row for size N=6
seq(Q(2,j,6),j=1..6);
               3, 5, 8, 14, 17, 26

Matrix(3,(i,j)->Q(i,j,3));
                  [1  2  6]
                  [3  5  7]
                  [4  8  9]

And here is a worksheet, for fun.

[edit] Don't take the timings too seriously. If you wanted better performance for the Matrix construction then I expect that you could Compile a decent procedure which walked the entries of the Matrix in bands using loops, and acted in-place (thus avoiding overhead of calling a Matrix initializer procedure on each entry).

Download mattrav_ac3.mw

@Thomas Dean Yes, it is strange indeed that you would not mention at the beginning that it was for a specific x value.

@nm Your interpretation of what is going on is not correct.

If you do the parse without the eval (or statement option, which induces an evaluation) then the variable ode is assigned the unevaluated expression. That happens whether done at the top-level or inside a procedure while assigning to a local name. What gets assigned to name ode is the same in both cases.

What makes a difference is the degree of evaluation when that assigned name ode is subsequently passed as argument to another procedure -- such as dsolve. In the top-level case it is evaluated, and in the procedure local case it is not.

The difference is in how the assigned name ode is subsequently evaluated (or not) when passed around. Contrary to what you suggested, the difference is not the degree of evaluation during the assignment to the name ode.

The 1-level of locals within a procedure is clearly documented on the Help page for Topic procedure.

What is incorrect is your surmise, "...semantics of assignment to local variable is different than assignment to the variable when in global context". The difference is not in the assignment to the local name, but in how it gets subsequently evaluated when referenced/passed.

Download parse_example2.mw

Which side buttons do you mean, left (palettes) or right (context-menu)?

Does it improve if you close the left panel and the right panel?

@AHSAN At lower working precision the floating-point evaluation of the expression (at different values of lambda) might suffer from roundoff error and inaccurate results might get be produced.

Presumably your expression is as you intended it.

You have asked about other rootfinding methods before (and been answered!). I see no reason to encourage you in such duplication of questioning, or to reinvent the wheel.

You are free to utilize your own numeric root-finding algorithms, and you might find the range lambda=0.4..0.85 helpful.

If I'm not mistaken, the original product expression P has -- as one of its multiplicands -- a 5th degree polynomial,
   57441.45187*lambda^5 - 174030.6883*lambda^4 + 209711.5508*lambda^3
   - 125674.0589*lambda^2 + 37467.33188*lambda - 4446.983589
which may be factored approximately to obtain this factor:
   lambda - 0.4632186949799427