Carl, you wrote that the problem was also exhibited when the problematic subsection was not empty. When it was not empty did it have a title?

I could be wrong, but it seems to me that the problem occurs when the <Title> XML element of the file does not contain its usual <Text-field> child element. In that case the GUI cursor cannot be moved to the title of the subsection, it seems, nor can the pointer device point-and-sweep from there (so as to delete just that subsection).

One remedy seems to be to point-and-sweep from other elements around it (similar to what John suggests). Another that worked for me here is to edit the file in a text editor and insert <Text-field></Text-field> inside the empty <Title></Title>. Of course that can be onerous to locate, if deep in the middle of a document.

Do you recall anything special about how that problematic subsection was originally put into place or inserted or edited?

acer

@MortenZdk You're welcome. As I mentioned the help page Description for the Explore command explicitly describes the situation in your Question. If you want to get an explored parameter's values into a procedure call then make the parameter get passed in via the procedure's arguments. The are also several examples where that is done in the so-called example worksheet for Explore (see help topic examples,Explore ).

@Doug Meade This is not about single level evaluation of procedure locals.

You made the typographical mistake Optimization-NLPSolve instead of Optimization:-NLPSolve, and so your return value is the result of subtracting the list returned by NLPSolve from the name Optimization.

You would have to have previously loaded Optimization, in order for that (short syntax) NLPSolve call to have succeded.

@ThU In Maple 2016 the help page for the Explore command mentions this situation in its Description. The third bullet point of that Description reads as:

       Parameter values are used by re-evaluating the original expression
       or function call. The parameter names are not assigned values in this
       process. In consequence instances of the unassigned parameter names
       within a procedure body will not be evaluated. In order to use the
       values within a procedure the parameter name should occur in an
       argument to an explored function call.

Its last sentence's suggestion is what you gave as your second alternative.

I think that the current behaviour is not wrong, on general grounds of how Maple's evaluation model works. For one thing it would be undesirable if Explore tried to temprarily assign to global :-a, especially if an un-catchable error during evaluation (of f here) left :-a assigned as side-effect. Note also that the test depends('f(x)',a) returns false.

Even if Explore tried to use its own internally constructed, modified instance of f (ie. subs(a=value,eval(f)) ) that would likely need to be expensively done for each value of the parameter. And worse still, if parameter a appeared within another proc that was called within f then it still would not be workable.

Maple's evaluation model is worth learning, and while the Programming Manual is a good start though doesn't cover everything.

In the past I have seen requests (some on this site, one from Preben?!) for a facility that would allow something like the following to produce 5*x for both outputs below:

restart;

f := x->a*x:

use a=5 in
  f(x), a*x;
end use;
                                  a x, 5 x

Such a facility (were it to exist, presumably by some langage keyword other that use) would be best if it were at least as strong as try..catch..finally in its ability to allow temporarily instantiated values to be forcibly undone.

@JrebL When exploring plots it can be help to use the view plot option, so that the visible extent of the axes is common across the various plots. (Of course, this may require that you figure out in advance a view which will include all the plot features that you intend to see.)

You may also wish to try using the scaling plot option.

Eg,

Explore( plots[arrow]
         (
           [ Vector( [cos(delta), sin(delta)] ),
             Vector( [2,-1] )
           ],
           view=[-1..2,-1..1], scaling=constrained
         ),
         delta=-Pi..Pi
       );

@tomleslie Thanks for the notes, Tom. I'd like to clarify a few items.

In question 2.) the name t won't get atuomatically made a local of the procedure `tiempo` since it is not assigned to. The name t is used only as a dummy variable for the fsolve call inside procedure tiempo. But (as you noted) Maple can try and pick up a value for t if it is assigned at some higher scope (than that of tiempo). I explicitly made t a local of tiempo so that the procedure would not accidentally pick up either a value for assigned global :-t or a t in a parent procedure which might have its local t assigned.

Related to question 3.) I used global name :-theta in the call to set the particular parameter value. I had to do that because the call to set a particular parameter value was being done inside the distancia procedure of my original Answer. But that distancia procedure has name theta used for its formal parameter (argument). So this relates to 2.) as well. A global name like :-theta can be used to avoid collision with both locals and parameters at the current or higher scope, and the uneval quoted form ':-theta' can be used to protect against picking up a value assign to the global name :-theta.

There is a help page with Topic colondash which does a somewhat OK job of detailing some of these things.

In general the safest and more robust methodology is to always used uneval-quoted global names for the lhs keywords of equation-form options to procedure calls. For example plot(..., ':-color'="Orange") . That example would work even if eventually used deep inside nested procedures some of which have the name color used as assigned local or formal parameter, or if global :-color has an assigned value.

I don't always use that safest form of uneval quoted global names for keywords. And neither do most help pages examples. Sometimes I do it when I guess that the user might utilize my Answer code in a way that needs it. It the case of distancia in my original Answer it was required for the procedure to function properly (as the two different kinds of name theta would otherwise clash).

I am not really sure why UseHardwareFloats had to be set to false in my original Answer, in order to get sensible values from distancia when used in Maximize. I looked only briefly at it. My first guess was that it was a problem with the automatically, internally generated objective gradient procedure that Optimization:-Maximize uses. I think I ruled that out as the cause, since providing my own carefully made objective gradient proc as an option for Maximize didn't fix it. Then I guess that it was a problem with convergence -- that Maximize might be having trouble deciding convergence due to less accuracy from the dsolve numeric results. I think I ruled that out too, by playing with distinct Digits and accuracy options. Then I tried tracing the numeric values being produced within distancia, and lo and behold I got rubbish values. That led me to guess that the problem might be in the evaluation of distancia under evalhf (done internally by Maximize). So I set UseHardwareFloats to false as a way to instruct Maximize to not use evalhf when doing objective function evaluations. My original Answer I did in  64bit Maple 2015.2 on Linux and my followup with events I did with 64bit Maple 2016.1 on Windows. I should follow it up and submit a bug report.

@Giulianot I'll answer your other questions when I get a chance.

But for now, here is the refinement of using the halting event of y(t)=0 , in order to make the numeric solver stop. This is more efficient than fsolving to find the time `t` when y(t)=0 , for each angle.

You can observe that this is much faster to plot. I wrapped in CodeTools:-Usage to demonstrate one way to time things in Maple.

And I've thrown in the inverse function, distance->theta.

In the actual worksheet there is a Warning emitted when calling xprueba(1000) and hitting the halt event, but the warning doesn't show when I inline the sheet here on mapleprimes.

See the help page ?dsolve,events for more about events. It supports quite a rich set of possibilities, although it can get complicated to set up for more advanced "manipulations".

Download proyectil_2.mw

@Carl Love Sure. Thanks for mentioning it.

But it's also not difficult to come up with examples where the unapply method falls down, say because the call f(x,1) fails to produce a single expression that encapsulate all that f is intended to accomplish. Examples include procedures f which branch according to the particular input (possibly when numeric), etc. It's possible that the given example was provided as a toy example (which happens to succeed with either approach), and that the OP has more involved procedures in mind. This is related to why D exists, and does more than just unapply a call to diff of an expression function call result.  [I know that you know all this, of course.]

@Carl Love Of course what you write is correct: there always being some example which will cause numeric problems for any given fixed precision environment.

AFAIK "machine precision" means something more like hardware double precision, and should be closer to about (just over) 15 decimal digits rather than 17.

In Maple the simplest way to get a hardware double precision computation for this example (which happens to be quite accurate for this particular example, off by just a few ulps) is to compute it within Maple's evalhf facility. Ie,

restart;
f:=x->(1+1/x)^x:

evalhf(f(31536000.0))
                      2.71828178130237097

That is done very quickly.

restart;
f:=x->(1+1/x)^x:

CodeTools:-Usage( evalhf(f(31536000.0)) );
memory used=0.98KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns

                      2.71828178130237097

And, for the OP, the final evalhf result can be easily re-evaluated to 10 digits,

restart;
f:=x->(1+1/x)^x:

evalf[10]( evalhf(f(31536000.0)) ); 

                          2.718281781

To the audience, see the ?evalhf help page for more details.

evalhf( DBL_MIN );
                                         -307
                   1.00000010000000008 10    
evalhf( DBL_MAX );
                                         307
                    9.9999999000000001 10   
evalhf( DBL_EPSILON );
                                         -16
                   2.22044604925031308 10   
evalhf( Digits );
                              15.

To be fair to Mathematica, it should be mentioned that it also offers a numeric computation model in which the working precision can adjust itself, per computation, using a proprietary significance arithmetic model (somewhat akin to interval arithmetic). In that scheme a specified precision on the inbound numeric quantities can be used to meet a target accurracy. In contrast, in Maple the `Digits` environment variable only promises a target accuracy for so-called atomic operations, and in compound operations such as the example at hand the numeric round-off error can accumulate. In general it is up to the user to find a `Digits` setting that produces an accurate result for floating-point evaluation of expressions involving compound computations. (I have a somewhat rough attempt at a user-friendly front end to `evalr` and `shake` which gives a more robust float evaluation of examples like this one, trying for target accuracy. Should I polish it up?)

solve( { not x<100 }, x)[1];

                                        100 <= x

Now, are you OK with the name being on the right hand side like that? If not you need it reversed then (since 'x>=100' automatically simplifies to 100<=x) you may need to use something like sprintf or nprintf to turn such offending beasts into something that prints with lhs and rhs reversed.

acer

@Carl Love I am not sure that you are right in thinking that the essential problem is something that has changed with respect to Matrix (rtable) evaluation.

Similar evaluation behavior can be recreated in Maple 2016 if one creates a Matrix using unevaluation quotes. Eg.

restart;

C11:=upsilon[21]:

P:=Matrix([['C11']]);
                                 P := [C11]

eval(P, [upsilon[21]=3.4]);
                                [upsilon[21]]

eval(copy(P), [upsilon[21]=3.4]);
                                    [3.4]

Q:=map(eval,P,1);
                             Q := [upsilon[21]]

eval(Q, [upsilon[21]=3.4]);
                                    [3.4]

eval(rtable_eval(P), [upsilon[21]=3.4]);
                                    [3.4]

kernelopts(version);
         Maple 2016.0, X86 64 WINDOWS, Feb 16 2016, Build ID 1113130

I suspect that the discussions of rtable eveluation is sometimes muddied a bit because elements are evaluated upon access individually (extraction) and by printing of the whole thing.

@vv The use of so-called 2-argument eval to get different instances of the Matrix (instantiated at each set of values of the parameters) is superior to repeated assignment of sets of values to the top-level parameter names, I would agree.

One partial reason that it does not work for the OP is that he has created his Matrix using the infernal Matrix palette in 2D Input, which through poor design includes (unnecessary and unfortunate) unevaluation around the parsed elements. (I have previously submitted a bug report against that...)

It is not strictly necessary to use rtable_eval in order to work around this. Mapping 1-level eval across C[iso] is also sufficient, and it need only be done once, with the result reassigned to name C[iso]. And after that the use of 2-argument eval to evaluate the Matrix at the list of points should work.

Of course, if the OP is dead-set on using the method of repeatedly re-assigning the parameter names (rather than use the 2-argument eval or subs to instantiate at a list/set of points) then the C[iso] Matrix would also have to be somehow copied each time since otherwise the re-assignments clobber each other. Here is a version of that approach, done with Maple 15. Forum_Question_alt.mw As Carl has demonstrated rtable_eval (combined even with 2-argument eval) may be another effective solution for the OP.

How was the file "transferred" across the network? 

There are some instances of things like webmail which turn XML files like Maple .mw into empty 0-length files. Often that can be avoided by transferring a zipped copy instead.

I don't see where you've indicated that .mw worksheets which have not been so transferred could or could not be uploaded by you from the problem network. That would be a useful thing to rule out.

Some people have reported an inability to inline their uploaded worksheets here. But you may still be able to Insert Link even if you cannot Insert Worksheet (inline its contents) in the upload popup dialogue here. Another useful thing to rule out.

acer

@Carl Love I have run across that problem where the plot is lightened while highlighted, and I too think that its ridiculous behavior.