@janhardo Your whole problem could also be rewritten and solved using expressions, instead of operators. (I believe that it might have been you who originally had the operator x->x^sin(x) or similar as an example. I mostly followed your cue, or used what was easiest for the example at hand.)

One is not better than the other, for all problems. But they are different. For example,

expr := x*sin(x);  # expression

            expr := x sin(x)

# Incorrect
# expr should not be applied to arguments
expr(4.2);

           x(4.2) sin(x)(4.2)

eval(expr, x=4.2);

             -3.660618244

diff(expr, x);

            sin(x) + x cos(x)

f := x -> x*sin(x);  # operator/procedure

           f := x -> x*sin(x)

f(4.2);

             -3.660618244

D(f);

          x -> sin(x)+x*cos(x)

Sometimes it is easier to use one instead of the other.

You can usually get one from the other, if you have need for both at different parts of your computation. Continuing with this example,

f(x);

           x sin(x)

D(f)(x);

       sin(x) + x cos(x)

unapply(expr, x);

         x -> x*sin(x)

unapply(diff(expr,x), x);

       x -> sin(x)+x*cos(x)

If you write code that expects F to be a procedure (ie. it uses D to differentiate, and applies F to values, etc) then you cannot simply assign an expression to F and have it all work OK. Likewise, if you write code that expects F to be an expression (ie. it uses diff to differentiate and uses eval to evaluate at a value, etc) then you cannot simply assign an operator to F and have it all work OK.

ps. If you do not like dealing with ranges then you could always change your procedure so that it accepted values for its 2nd and 3rd parameters (the end points, individually). You could do that instead of having the 2nd parameter be a range which had to be further split up by the code. One way is not significantly better than the other.

@janhardo You also passed your procedure Tangentlines an expression for its first argument, whereas it was set up (like all other examples in the thread) to handle an operator/procedure. I corrected that too.

The operands of a range are its end-points. You can extract those operands using the op command. You can also extract them using the lhs and rhs commands, which I think looks more natural.

rng := 1 .. 16;

        rng := 1 .. 16

op(rng);

           1, 16

op(1,rng);

             1

lhs(rng);

             1

op(2,rng);

             16

rhs(rng);

             16

It wasn't clear to me whether you'd also seen the two attachments in this prior Reply.

@janhardo You introduced several mistakes, which I've corrected/reverted.

betounes_ex_set_2_opg_6via_codeexample2.3_uitwerking_acc.mw

@Scot Gould 

In the Help page for topic procedure, (also available in Maple's Help system) there is a Section Evaluation Rules which contains this:

  Within a procedure, during the execution of its statementSequence,
  local variables have single level evaluation. 

In the Programming Guide (also available in Maple's Help system), Chapter 6 Procedures, Section 6.6 How Procedures Are Executed, subsection Statement Sequence Interpretation, subsubsection Variable Evaluation Rules within Procedures:

  Maple fully evaluates global variables whenever they are
  referenced, even within procedures, but local variables are
  evaluated in a special way. When a local variable is
  encountered during procedure execution, it is evaluated only
  one level.

That is followed by an expository example and further explanation.

@janhardo The comamnd with is not intended to work within a procedure body (see its Help page). Instead, you can either call commands by their full names, eg. plots:-display , or you can utilize the uses functionlity. See the attachments for examples.

betounes_ex_set_2_opg_6via_codeexample2.3_ac.mw

betounes_ex_set_2_opg_6_ac_ex3.mw

@janhardo The failure of your very last example has nothing to do with maplemint.

In another thread, in my very first Answer to a duplicate of this topic, I suggested the Roots command from the Student:-Calculus1 package as a way to compute numerically a modest number of roots of a univariate expression over a purely real range. The only reason I ever gave a straight call to fsolve was because you (or your book) demanded it. But several ways were provided. You could try them. Here is your followup example, using Roots,

Download betounes_ex_set_2_opg_6_ac_ex2.mw

Given any numeric rootfinder you will be able to find some example that defeats it.

Which version of Maple are you using? For example, 2018, 2019, 2020?

Which version of the Gym package are you using? 2018, 2019, 2020? Did you install it yourself, and make sure that it was the correct version for your Maple?

Upload and attach a Document/Worksheet that contains the problematic example, run after a fresh restart. If you can also have it contied the Copy&Pasted exampel that work properly, then that'd be even better.

Does the Copy&Pasted example also work if you paste in into an Execution Group instead of a Document Block (paragraph)? Even if you paste it in as 1D Maple Notation code? Having these also in your attachment could help.

@radaar If you read my Answer closely enough, you would see that I stated that the procedure is the same whether the locals are declared explicitly or implicitly. The procedure is the same, either way.

Let's see that:

ff:=proc() a:=a+10: return a: end proc:
Warning, `a` is implicitly declared local to procedure `ff`
print(ff);

       proc() local a; a := a + 10; return a end proc

gg:=proc() local a; a:=a+10: return a: end proc:
print(gg);                                      

       proc() local a; a := a + 10; return a end proc

evalb(eval(ff)=eval(gg));

                      true

evalb(ToInert(eval(ff))=ToInert(eval(gg))); 

                      true

I also stated in my Answer that the local declaration is something that becomes a part of the procedure as soon as it is defined. So, the "localness" of `a` will hold throughout the procedure, and not occur, say, just when it gets assigned.

Also, your followup Comment stated that the "output" was a+10 . But that's just the return value. The output in my session also includes the message about `a` being declared local to `ff`. This is also true for your Question's second example.

restart;

a:=10:

ff:=proc()
  a:=a+10:
  return a:
end proc:
Warning, `a` is implicitly declared local to procedure `ff`

ff();
                 a + 10

In the second example of your Question you commented that `b` is an "implicit local". But `a` is also an "implicit local", for the very same reason.

The second one doesn't follow your original description. Originally, you wrote: "g(−3) returns g(3)".

If what you actually meant was that g(-3) should return the same thing as what g(3) returns then the original description was incorrect.

That contradicts your original description's implications.

You see, your original description implied that g(10) would return g(-10) and also that g(-10) would return g(10). If both of those hold then g(10) - g(-10) won't return 0. Instead, it would return g(-10) - g(10).

However, here are two variants, for both of which your followup condition  g(-x) - g(x) = 0  holds:

g := proc(ee)
  if sign(ee)=-1 then 'procname'(-ee);
  else 'procname'(ee); end if;
end proc:

g(10);
                   g(10)

g(-10);
                   g(10)

g(-10) - g(10);                       
                     0

g(x);          
                    g(x)

g(-x);         
                    g(x)

g(-x) - g(x);  
                      0

and,

g := proc(ee)
  ('procname'(ee)+'procname'(-ee))/2;
end proc:

g(10);                                                     
               1/2 g(-10) + 1/2 g(10)

g(-10);                                                    
               1/2 g(-10) + 1/2 g(10)

g(-10) - g(10);                                            
                      0

g(x);                                                      
               1/2 g(x) + 1/2 g(-x)

g(-x);                                                     
               1/2 g(x) + 1/2 g(-x)

g(-x) - g(x);                                              
                       0

I am having trouble downloading the attachment from the link. Could you try relinking it? (Perhaps give it a simpler name, with only alphanumeric characters? Though I don't know whether that is the issue.)

ps. In one of those older threads I made a comment about a reusable procedure to generate an actual (scaled, inset) subplot.

@janhardo If you are beginning in programming in Maple, and if you want something gentler than the Maple Programming Guide, then I would recommend this recent book:

   Understanding Maple, by Ian Thompson

It is not expensive, is relatively new (2017), and is really quite good and straightforward. I have only a few quibbles with it. Associated worksheets are available from the author's homepage.

Another good book -- by someone with good experience in teaching with Maple -- is the following, older (2009) book. The author still has the associated worksheets available for download at his website.

   Getting started with Maple, 3rd ed., by Douglas Meade et al.

@janhardo The procedure in the shown image has a side-effect assignment on one of the arguments.

There are a few stock Maple commands that use such side effects as a way to accomplish an additional return value -- ie. in addition to the main returned result. But it was mostly only done that way because in the very distant past procedure calls could not do multiple assignment -- ie. return a sequence and assign to a sequence of names. 

It has never been a good Maple programming practice to use such a side-effect instead of doing any return value, which is what the procedure in the image does. This is further evidence that the book is not very good.

Similarly, having a procedure assign to a declared global instead of making any normal return value is not good practice.

For Maple versions 2018.0 to 2020.0, stored values for nonderived and adjusted constants appear to match what is in the published CODATA 2014.

For example,

ScientificConstants:-GetConstant(h);                                              
                                                    -33                       -41
Planck_constant, symbol = h, value = 0.6626070040 10   , uncertainty = 0.81 10   ,

    units = J s

The ScientificConstants references help page of Maple versions 2018.0 to 2020.0 indicates that the CODATA site was last accessed in 2015.

The ScientificConstants updates help page indicates that, since Maple 9, the methology of deriving additional values follows what was first advocated by NIST in 1998. See,
   P. J. Mohr and B. N. Taylor, Rev. Mod. Phys. 72(2), 351-495 (2000)
Unfortunately, the 2014 CODATA adjustment is not cited on that Maple help page.

Addionally, the set of CODATA values now published is larger. For example the current set also contains certain reciprocals. Accomodating any additional "adjusted constants" could be useful, though that might involve some awkward naming issues. See,
    P. J. Mohr, D. B. Newell, and B. N. Taylor, Rev. Mod. Phys. 88(3), 035009 (2016)

A more recent "CODATA 2018" collection of values has been available since May 20, 2019. These could be used to update the values stored in Maple. See here

@vv The evaluation done inside that SEQ will not always produce the same behaviour as seq, if the example is executed within some procedure for which a is declared local.