My response to your Q3 relates to removing warnings from a precomputed worksheet file.

At the risk of stating the obvious, you might also rerun the worksheet with all warnings disabled, by executing this command at its beginning:

    interface(warnlevel=0):

@Tycho Brahe Some of these responses relate to my own preferences, grown out of several decades of Maple work.

"0. The most important  thing I'd like to learn is why Assume (the way I wrote it does not work)."

In this case you are conflating a computation done with mathematical implications (due to some assumption) with substitution according to some formula.

"The reason: It is cumbersome to keep asserting the same thing at every step."

You are free to assign an equation to a short name, and then use that more than once.

Moreover, even for an example where assumptions were suitable, I much prefer utilizing assuming (when needed, multiple times if necessary) than assume. There is a lot of tricky waters that users often get into when trying to build and intermix expressions containg the "same" name with assume assumptions on it, without such, and with additionally followups.

"1. What's the difference between MatrixInverse(U) and MatrixInverse([U])?"

I don't know what you mean there by the square brackets. Do you mean a list, or a 2D typeset Matrix input, or...? If a Matrix has been assigned to U then MatrixInverse(U) should compute. Apart from casting to floats or sepcifying some indexing function I see little to no virtue in wrapping U (even if it were valid...). I don't understand why you're asking this.

"2. If Assume doesn't work as I used it, then what is its intedned use? maybe using a simple example"

The assume command is old. The more modern assuming is my personal preference where possible, even at the expense of more typing, as assume is quirky enough to irritate me more often that aid me. See also my response above to your 0).

I also prefer to see the assumptions being utilized -- beside a computation's input -- when I read it later on.

There are examples in the documentation.

".3. If I denote r' as "atomic" then it seems that typing r' in the next line still returns "dr(x)/dx" (nevermind r(x) was never even defined) but if I copy/paste the atomic symbol from the previous line, then it seems to recognize r'. Is this correct?"

I mentioned that you'd have to ensure that each such input is the so-called atomic variable instance. If you're lucky your Maple version will successfully let you copy&paste one such instance to other inputs. If you're unlucky in that respect then you might have to right-click convert each time, or use some other easy name to which it's been assigned, and only see the effect in output. That's what I was trying to convey before. (I don't suggest assigning the "atomic variable" form to the remember table entry of diff. which sounds like asking for confusion.) There are hints that you might be able to do this task under the physics package -- now, or soon -- but I don't know whether that would make your Maple syntax learning easier or harder.

@NHameed What range do you want to consider, for the roots? How many roots are you interested in?

fsolve(cos(x)*cosh(x)-1, x=0..20, maxsols=7);

    0., 4.730040744, 7.853204624, 10.99560783, 14.13716549, 17.27875965

By the way, did you read my Answer to your original query?

I changed your Post into a Question, because it consists of questions.

I forgot to mention (sorry, I cannot edit my response at the moment): you could also call
   indets(expr,`+`)
to see all the subexpressions on which the inner procedure would operate.

@nm The subsindets call applies its action (its 3rd argument, here an anonymous procedure) to all subexpressions of type `+`. That is how that procedure gets called more than once.

Here is one way to see its actions, using option trace on that anonymous procedure.

Download subsindets_examp_explained.mw

You could also assign that inner procedure to a name and pass that as the 3rd argument to the outer subsindets. Then you could trace or debug it by name.

I can't seem to edit previous replies right now...

Even terser, but perhaps more obscure (which often I don't prefer),

R := expr -> subsindets(expr,`+`,
  ee -> local u := selectremove(type,ee,specfunc(f));
        u[2] + `if`(nops(u[1])=1,u[1],f(map(op,u[1])))):

Messing around can make it important to test all the corner cases.

This is a terser way to implement that idea,

R := expr -> subsindets(expr,`+`,
       proc(ee)
         local u := selectremove(type,ee,specfunc(f));
         u[2] + `if`(u[1]=0,0,f(subsindets(u[1],specfunc(f),op)));
       end proc):

In either implementation of this idea the key part is to separate all the function calls to f, as a first step. That allows you to avoid using the type `&+`, for which the dependency of the relative positions of its arguments was getting in your way.

@emendes Using Maple 2019 (or later),

[for t,v in eval(T) do `if`(v<>NULL,t,NULL); end do];

   [7,11,15,19,16,22,21,26,25,30,28,37,38,32,41,48,49,60,58,57]

[for t,v in eval(T) do if v<>NULL then t end end];

   [7,11,15,19,16,22,21,26,25,30,28,37,38,32,41,48,49,60,58,57]

@AE98 How tragic; I had it repaired with contents visible. It must have re-corrupted when I saved the file. In fact I now see that happening, even inducing some additional loss.

You could try the following attachment:
Assignment2_ac2.mw

@Earl I don't see how any of the other responses can directly search Maple's 2D Input, since that is stored in a .mw file as a base64 encoding of a .m (dotm) Maple encoding.

@Earl You have not yet clarified whether you need to deal with searching 2D Input.

Here is a rough illustration of the approach I mentioned.

Download file_search.mw

Of course, for plaintext .mpl or .txt files there are more efficient tools. But that's beside the point if you need to search through 2D Inputs.

note: Worksheet:-WorksheetToMapleText has some limitations, eg. it cannot handle embedded components (and possibly GUI Tables).

Please don't spawn a completely separate Question thread for a close followup query about this system.

You could add your followup details here, instead.

@Carl Love It did contain Danish characters.

The past four or five corruption reports have all been of the same flavour: an unclosed and empty Equation XML element. I'd never seen that particular variant prior to Maple 2022.2.

I have submitted them all as bug reports. In each report for this past group (five of this same variant, Dec2021-Feb2022) I have mentioned two distinct flaws:
  1) that it happens at all
  2) that the GUI is incapable of recovering as much as possible from the corrupted file, and sometimes very little of what is possible.

ps. These corrupted files do not have the "bad characters" for which Joe Riel made a repair script some years ago. That was a different flavor of problem -- which I do not recall seeing for several years.

Why do you think that your procedure's do-loop would ever end?