@Carl Love If it is expected behavior that numcpus can only be set once per session then certainly the help page for the kernelopts command should mention that fact (and on the same help page some other key should be used to illustrate the way that kernelopt's return value is the previous value for the given key, etc).

@Carl Love When doing some experiments a few years ago I recall noticing that I could only get the kinds of expected performance difference if I set kernelopts(numcpus) once per restart, before doing other computations. I was likely doing this on 64bit Linux.

However I have not tried that recently. And the computations I was doing were likely hardware double-precision under evalhf or Compiled procedures running in Threads:-Task (or, less likely, double-precision LinearAlgebra) all inplace on float[8] rtables with no garbage collection.

I may even have set kernelopts(numcpus) from the Startup Region of a Document. I don't recall the full details. But I did see the expected performance scaling, from 1 up to the number of physical cores.

I don't know what's going on with Threads:-Mul or Threads:-Add however, even on a given platform, including the case of exact computations that includes garbage collection.

@Østerbro Your latest objection is not related to units specifically, but would also occur for some other examples without units.In large part the problem comes from incomplete specification of exactly what you do and do not want to see. Additionally, some of what you are now claiming sees to me to contradict earlier descriptions.

I suggest that you try to formulate a proper and precise description of what is meant by intermediate steps and intermediate results. I can understand that intermiate results should all be unique. But why not object earlier to unitless examples that exhibit some of your present problems. Please describe exactly what you want to see.

You could try the following,

Display:= proc(e::uneval) 
uses T= Typesetting; 
local 
     pre:= subsindets(e, uneval(name), eval, 1), 
     r:= eval(pre), 
     Ty_pre:= T:-Typeset(e) 
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then 
          print(r); 
     else 
          print(( 
               Ty_pre =  
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi), 
                    proc(n) 
                    local pn:= eval(parse(op(n)));
                         if pn::numeric then
                              T:-mn(sprintf("%a", pn));
                         else Typesetting:-Typeset(Typesetting:-EV(pn));
                         end if;  
                    end proc 
               )) = 
               evalf(r) 
          ) 
     end if; 
     r 
end proc:

And if that doesn't satisfy your goal then you could try this weaker variant,

Display:= proc(e::uneval) 
uses T= Typesetting; 
local 
     pre:= subsindets(e, uneval(name), eval, 1), 
     r:= eval(pre), 
     Ty_pre:= T:-Typeset(e) 
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then 
          print(r); 
     else 
          print(( 
               Ty_pre =  
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi), 
                    proc(n) 
                    local pn:= eval(parse(op(n)));
                      if pn::numeric then
                           T:-mn(sprintf("%a", pn));
                      elif type(pn, numeric &* 'specfunc'('anything',Units:-Unit)) then
                           Typesetting:-Typeset(Typesetting:-EV(pn));
                      else n;
                      end if;  
                    end proc 
               )) = 
               evalf(r) 
          ) 
     end if; 
     r 
end proc:

Your XP machine seems to be 4 physical cores without hyperthreading capability, while your new Windows 7 machine seems to be 4 physical cores with hyperthreading capability (which you utilize in your run using 8 cores).

With your XP machine your are comparing using 2 physical cores versus using 4 physical cores. But on your newer Windows 7 machine your are comparing using 4 virtual cores (from 8 available on 4 physical cores, since presumably you did not disable hyperthreading for that run) versus 8 virtual cores. On the Windows 7 machine it's quite possible that the OS distributed the load evenly amongst the 4 physical cores, in the run that used only 4 cores.

There was a time when hyperthreading performance was poor enough that it negatively impacted some parallel computations. But even with newer machines where that degradation is less severe the comparison between 2-physical-cores/4-physical-cores versus 4-phyical-cores/8-virtual-cores should not be expected to demonstrate the same performance ratios. Keep in mind that there are usually more ways in which virtual cores can have to contend for the same resources, but hyperthreading performance is a complicated topic.

acer

@Østerbro I'm not around so much these days, taking some summer vacation. But I'll have a look.

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.]