@Kitonum The infix syntax K%.U that you've shown will not work in 2D Input in Maple 2021, which the OP has shown to be using.

It will instead parse % as the previous result.

@Rouben Rostamian  Yes, they do solve the original equation, and no, they are not spurious solutions.

@RezaZanjirani You can upload and attach worksheet (.mw file) using the green up-arrow in the Mapleprimes editor.

Alternatively, you could use Maple's lprint command to get a plaintext form of the expression(s) that you're passing to the solve command.

@Sphericalmoments You wrote, "I thought "GenerateBipartiteTournaments" is an available package in Maple."

Why did you think that?

Did you see someone use that command somewhere? Did you see something similar? Is there a reason not to explain in detail?

Please stop changing the Post to a Question, which I address to whomever keeps changing it.

The OP is reporting on a bug, and it's primariliy a technical discussion of that.

Doesn't your expression simplify to approximately zero (and if the floating-point coefficients are converted to exact rationals then exactly zero)?

If so, then isn't the ensuing plot just a representation of the numeric roundoff error incurred by floating-point evaluation at numeric values for x and t?

In other words, isn't your plot simply showing zero + roundoff noise?

I have deleted at least two duplicate Question threads by this member on this topic, or close example.

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.