Do you mean the Help page with Topic  rtable_indexing ?

Or are you looking for help with function calls of an indexed name, such as, say,

F[bar]( some_args )

Or are you looking for the (uncommon) prefix-form indexing operator,  `?[]` , eg,

`?[]`(K,[1,2,3]);

               K[1, 2, 3]

You can use solve(E) to obtain all the roots of this particular example exactly.

You could also use fsolve(E,x,complex) if floating-point approximations were acceptable to you.

The select and selectremove commands can be used to separate the list of roots for various properties.

Download select_example.mw

It is just as easy to separate out the roots which are real and positive, etc.

Download simptrig_example.mw

You could get that even smaller under certain assumptions on a and lambda. For example,

There were not many edits or syntax mistakes, to my eye.

I had to change two instances of square brackets to round brackets, for delimiting a term of an arithmetic expression.

I had to change the procedure parameters from r[D] and t[D] to r__D and t__D (as typed in 2D Input mode, for literal subscripts which are symbols in the proper sense).

Your use of exp(...) in 2D Input mode was fine. (Evidence for that, in advance, was the fact that the "e" rendered in Roman upright rather than italic.)

I turned the a(i) computations into a loop, to shorten it.

Please check it over.

Download DifficultFunctionac.mw

You could try to install the last point-release update to Maple 2019.2.1 .

(I am not sure that it will help your case, but it's possible that point-release fixed a rare issue with licensing misidentification.)

Your followup comment ignored my point about the term Lambda(p-1) which is a function call and not a multiplication.

Perhaps you intend something like this, using Lambda*(1-p) instead. Here, the explicit solutions can be considerably reduced in length by simplifying.

restart;
Sol:=[solve({sigma*E-(mu+alpha+g)*II = 0,
             g*E+Lambda*N*p-(mu+alpha)*R = 0,
             Beta__1*S*E+Beta__2*S*II/(II*M+1)-(mu+sigma)*E = 0,
             Lambda*(1-p)*N-mu*S-Beta__1*S*E-Beta__2*S*II/(II*M+1) = 0},
            {E, II, R, S}, explicit)]:
Sol := simplify(Sol):

#map(print,Sol):

That works fine for me. The rsolve call worked, but I'll keep your other two procedures as well.

I'm not sure whether you are trying to find a point of intersection, so I'll throw that in too.

Download JAMET_suite.mw

You need to either load the package first (only once needed, per restart), or call it with its full name.

That is,

   with(Optimization):
   Maximize(2*x^2 + 2*y^2 + y, {2*x + y <= 6, y^2 - x <= 2});

or,

  Optimization:-Maximize(2*x^2 + 2*y^2 + y, {2*x + y <= 6, y^2 - x <= 2});

[edited] Many Help pages for exported commands of other packages contain the following kind of boilerplate usage message. The Help page for Optimization:-Maximize doesn't seem to have it. I'll submit a bug report.

  This function is part of the LinearAlgebra package, and
  so it can be used in the form LUDecomposition(..) only after
  executing the command with(LinearAlgebra). However, it can
  always be accessed through the long form of the command by
  using LinearAlgebra[LUDecomposition](..).

Stop using the syntax for creating operators/procedures in order to assign expressions.

If you are not trying to create a procedure (of one parameter, say x), then simply use an expression.

f := a+b;

             f := a + b

a:=5;

               a := 5

b:=2;

               b := 2

f;

                 7

Moreover, stop trying to use any syntax like,
   M_Inwendig2(y) := ...
or,
   M_Inwendig2(94) := ...
in 1D Notation. That assigns into remember tables, and it is not what you need.

You probably learned the (very poor) syntax for creating procedures in 2D Input, like so,
    M_Inwendig2(y) := ...
That will not work at all like you need in 1D Maple Notation input. Use unapply instead of the above, to create an operator from a prior expression. Eg,
    M_Inwendig2 := unapply(..., y);
That kind of mistake happens in many places.

If you had correctly set up M_Inwendig1 as an operator, for example, then you would not need to do all this just t get a float result:
   M_Inwendig1(105):=subs([y=0.105],M_Inwendig1(y));evalf(%);
Instead, you'd just have to call,
   M_Inwendig1(105);
That kind of mistake happens in a many places.

The entire document could be much simpler if you were to use expressions throughout (and 2-argument eval in a few places, for substitution). But you have chosen to use operators everywhere, even when not necessary. That makes it more confusing that it had to be (and leads to all these mistakes with remember tables and so on).

I will try to fix up parts of your worksheet, but there are many, many problems it's in quite a muddle. Here is part of it; it will likely need more correction and with so many changes it is hard to not overlook things: Wis_BS2_Taak2_2019-2020_20200323-1_ac_try1.mw

You have assigned an expression to T, not a procedure. The distinction is fundamental. You should't call the expression form with an argument here.

Also, if you want differentiation of expressions with so-called prime notation to denote differentiation by d then you need to inform Maple of that desire (I used Typesetting:-Settings for that, in the first example below.)

So, here are several ways, the first collections with T as an expression and the latter with T as a procedure (operator). You can use diff or D (as appropriate), or prime notation, in each scenario.

Download primenotation.mw

(I used Maple 2019.2 for this, to match the Question's heading.)

It is unclear what you are trying to ask, about "mathtype".

Is this something like what you are trying to accomplish in Maple 2016?

help_limit_ac.mw

You haven't been very specific about what aspect you don't think is good. Is it that it the over-symbol is in italics? Is it the offset distance from the central character? Is it the relative size?

You could try these (there are a few other choices, but you'd need to be more clear about what you want for me to try...)

Also, it's not clear to me whether you want a check mark or something else.

`#mover(mi("π"),mi("^"))`; 
`#mover(mi("π"),mo("^"))`;
`#mover(mi("π"),mn("^"))`;
`#mover(mi("π"),mi("∨"))`;
`#mover(mi("π"),mo("∨"))`;

Here is one way, which you can easily adjust.

Wis_BS2_Taak2_2019-2020_20200319-2_ac.mw

For your Linux you might try the following (I was on ubuntu 18.04).

This is a before and after comparison. I am guessing that this will affect the inmem=false use of Compiler:-Compile, where that would use gcc on a generated C source file. I am less sure about the default LLVM for inmem=true.

I'm supposing that you already have a test case for which you expect to be able to detect the difference.

Download compiler_opt.mw

You wrote, "... to prevent this inflation of random variables..."

Does that mean that you are trying to improve performance or conserve memory?

The modules that contain the details of the distribution instances take up some memory, and there may (eventually) be a noticable overhead due to global name accumulation and the cost of .mla initial checking of additional global names.

If you unprotect and unassign the _ProbabilityDistributionXXX instances then their referenced modules may still hang around (with memory-based names like _m140554330413728 and so on). Getting rid of them altogether could require getting rid of all references to them (including _RXXX names and anything else).

Or do you have only a modest number of such distributions, and you simply want to be neat and tidy?

Or do you have some other motivation?

note: I know that it can get quite awkward (because it's not convenient to utilize in the content of eval or use or assuming), but is it not at all possible to utilize the generic RV instantiation and re-assign specific values to the parameter name? For example,

restart;
with(Statistics):
x:=RandomVariable(Exponential(a)):
a:=2:
Mean(x), Sample(x,1);
              2, [8.23569715700137]
a:=1:
Mean(x), Sample(x,1);
              1, [1.43494745936376]