The first pair of parantheses (brackets) does grouping of terms, to assist with the precedence.

The second pair of parentheses does the functional application, ie. forming function calls.

Here is an example of only the second kind:
    sin(x)

Here is an example of both kinds in use together:
    (sin+cos)(x)
which returns   sin(x) + cos(x)  .

The following shows the role of grouping. Compare these two examples:
    (f+g)(x)
which returns   f(x) + g(x)  .  And now,
    f+g(x)
which returns   f + g(x)   which is the addition of the term f and the term g(x).

The first pair of brackets in   (f+g)(x)  serve an important purpose, for grouping of terms, which makes it quite different from say   f+g(x)   .

The key thing here is which takes precedence -- the function application or the addition. The first pair of parentheses in  (f+g)(x)  allow us to force the addition as preceding or taking precedence over the function application denoted by the second pair of parentheses.

Now something subtler. Suppose that g is unassigned at present, but later on may get a meaning such that g(x) returns something which can itself be applied to arguments. The expression  g(x)(t)  denotes the symbolic placeholder g(x) applied to argument t. So, we can meaningfully apply g(x) to something else, and use it like an operator.

In this rich world we could compose operator f with the placeholder g(x) for some (as yet unknown operator).  So now,
    f@g(x)
denotes the composition of those two operators, f and g(x). This conceptual composition of operators is not itself being applied to an argument. But the result is indeed a meaningful expression, and is not nonsense.

Now compare that last example with this,
    (f@g)(x)
which represents something quite different. This denotes the composition f@g applied to argument x, which results in   f(g(x))  .

The first pair of brackets in   (f@g)(x)  serve an important purpose, for grouping of terms, which makes it quite different from say   f@g(x)   . 

The key thing here is which takes precedence -- the function application or the composition. The first pair of parentheses in  (f@g)(x)  allow us to force the composition as preceding or taking precedence over the function application denoted by the second pair of parentheses.

I hope that helps some.

From some of your other recent Questions it seems that you are interested in module programming for involved purposes, eg. your large automated integration and differential equations solving and testing. In other words, likely some serious, involved, and lengthy code.

I suggest shooting for code maintainability over convenience.

I also think that qualified module references are much superior to so-called short-form names, in lengthy production-quality code. For example, I strongly prefer B:-foo() over just foo() following uses or use or with. I think that it's important that the code be managable, and is legible, understandable and naturally unambiguous. I think that is a far better way to manage the name-space.

If you really prefer terser code, for reading, then the qualified module references can be made shorter. Control of that can be done without having to utilize the uses functionality.

I also think that large amounts of valued code for procedures and modules should be kept in plaintext files -- for safety and robustness of the format, as well as for the ability to do good revision control.

Having said all that, I suggest a plaintext file format (which can be accessed in the GUI using the read command), that might look something like the following. Here the actual names of the modules and submodules can be easily changed later on, because they are defined in a centralized manner.

This is just an example,

$define AM=Amodule
$define BSM=Bsubmodule
$define CSM=Csubmodule

AM:=module()
   export BSM:=module()
     export foo:=proc()
         print("In foo()");
     end proc;
   end module;

   export CSM:=module()
      export boo:=proc()
           BSM:-foo();
      end proc;
   end module;
end module:

$undef CSM
$undef BSM
$undef AM

How about,

    `.`( seq(A[i], i=1..n) );

Naturally, n would be some actual integer.

Did you first embed a Speaker Component, say from the Embedded Components palette?

Did you check that the identity property of the Speaker Component matched the second argument passed to the Play command?

Do the other right-click properties of the embedded Speaker Component look reasonable? (eg. not muted, volume>0, driver device looks right, etc)

Download code_Int_ac.mw

That kind of labeling is available in the Command Line Interface (aka CLI or TTY), and in the Classic GUI.

It is not enabled with default settings in the Java GUI. But it can be enabled by adjusting various interface settings.

Unfortunately the line-breaking doesn't work properly in the Java GUI, for such labeling. Which is a shame because (when working properly) it is a very nice feature. It can make a long expression legible and comprehensible, that would otherwise take many pages to pretty-print.

Download expr_labeling.mw

In some situations the LargeExpression package has some related utility.

And there are also the GUI Equation Labels, which have a different utility.

It's not clear what range for x you wish to allow, or what upper bound for k you wish to consider, or whether you want the plot to illustrate k values.

Here are some ideas. You can solve synbolically for x that make k positive (or not).

Download pw.mw

There appears to be a corrupted Plot XML element (I think in section Opg 3 of Rumintegraler Uge 6).

With that bad element removed, the remaining contents are available, see attachment. This recovers twelve Sections, up to Uge 12. (The Maple 2021.0 GUI could, sadly, only recover the first five of those.)

matOpgaver_1_ac.zip

I strongly suggest that you keep your own regular backups of lengthy and precious assignments done as Maple worksheets.

[edit] I will add this to my collection of earlier reports of corrupted worksheets of Danish students. I'll have to repeat my earlier notes that the manner in which the GUI "repairs" corrupted XML elements could be significantly improved..

@tarik_mohamadi The expression Bi-1 divides both the real and the imaginary components of the determinant expression (eq), under the assumption that remaining parameters are real.

I could get the following (avoiding source=csv, as an option),

Download nm_ImportMatrix.mw

I suggest:

 -- The Programming Guide

 -- Understanding Maple, by Ian Thompson

The first comes bundled with Maple, in its Help system.  The second is relatively up-to-date (2016), well written, brief yet to the point, mostly of good sensible quality, and inexpensive.

If you are going to program in Maple then I suggest you start off by toggling your GUI default modes to:
  -- Worksheet, instead of Document
  -- 1-D plaintext input "Maple Notation", instead of typeset "2-D Math"
(See Tools->Options->Display and Tools:-Options->Interface, respectively.)

How about StringTools:-SubstituteAll, replacing with the empty string?

s:=" \\left \\int x \\,dx \\left":

StringTools:-SubstituteAll(s,"\\left","");

          "  \int x \,dx "

I don't know whether you care about residual white-space,

with(StringTools):
SubstituteAll(SubstituteAll(SubstituteAll(s," \\left ",""),
                            "\\left ",""),
              " \\left","");

          "\int x \,dx"

After issuing stopat(proc1), you need to actually run an example that calls that proc1 procedure. Then the debugger will appear, when the computation invokes that procedure.

I don't think that you should compute the plot as you describe with a fixed z-step-size, eg. by passing the adaptive=false and say numpoints=floor((9-2)/0.5)+1 options to the plot command (modifying how Tom called it). The result would be very coarse.

Tom's suggestion utilizes the default adaptive plotting of the plot command, sampling Z over the range -5..5 according to where it ascertains that more points would help. (This is true whether the z-range is 2..9 or -5..5.)

The computing time for Tom's adaptive plot call can be roughly halved by memoization (eg. storing the fsolve results rather than calling it twice, once for each of x and y).

But if you're willing to experiment with (or compute) the x- and y-ranges then for the example Tom invented even smoother curves can be obtained, and much quicker, eg. through the implicitplot command.

There are also regions in which the plots from the two methods visibly differ (eg. where the curves become steep/multivalued). I leave it to you to judge.

Download impl_fun.mw

Is there a special reason why you haven't provided us with your full example, so that we could test out ideas?

Editing your original.

In the Maple GUI the results from the loop are actually shown for all three of i=1..3 . It's a quirk of this forum that they don't each render when inlined here.

You don't have to use a loop, of course. But I prefer indexed L[i] to concatenated L||i .

Download Lagrange_interpolation_ac.mw

Perhaps more graceful would be a revision to procedure Lg, such that it accepted lxi as an argument, and deduced n=numelems(lxi).
 

(This seems a tiny bit tidier than your followup A_little_example_ac.mw )