@Carl Love Indeed I had imagined that handling the objective repeatedly (say, as some additional parameters changed while the objective continued to be formed in part by those main variables) would mean that by far the simplest solution would be to not assign to the main variables. I quite agree, making the assignments would be the awkward/wrong way to go, in that situation.

I'm hoping that a worksheet will be uploaded so that, in this likely scenario we could provide the full solution.

The Question indicates to me that the OP is not aware of any way to make use of the NLPSolve solution even once. So I've given such. If he needs to loop, and re-use those names in a running version of the objective, then indeed he should use the two-argument eval method and not use assign.

@tomleslie That thread is not related to this Question.

That whole thread was a bit weird, actually, as the only reason Admin privileges were needed was because the hdb file was unwisely placed in the lib subfolder of the actual Maple installation. Putting it into a toolbox folder (as I did in my attached answer here) is much better.

But in any case the two Questions are about two different things and the suggestions in the thread you cite will do nothing at all to aid here. It just muddied the waters by citing it at all.

@digerdiga If you call evalf(int(...)) instead of evalf(Int(...)) and the end-points are not floats (and if you didn't pass the option `numeric` to `int`) then it will first try to compute the integral symbolically, and that can be expensive. And if would do that for each invocation, thus even more expensive when looped. This is a common mistake in usage when someone is intending to do purely numeric integration.

The term you were originally looking for is re-entrant, rather than thread-safe, I suspect. And, yes, it is supposed to be.

@a_simsim You're most welcome. Please forgive me if I restate the following. The basic problem was that simply computing 

VEHQD( 1.0 );

outside of Explore was also not working. It's usually helpful to ensure that the explored thing works on its own outside of any Explore usage, with actual values supplied for the parameters.

@emendes Please note that on the first usage (which creates the toolbox folder and the .help file) the added help page will not be accessible upon help query. The GUI must be fully closed and relaunched from the desktop, and then try the help query.

Keep the location for the .help file specied by me (ie , the "toolbox" location). That's what makes it work automaticallt upon relaunch. Otherwise you have to put the .help file in the Maple installation's "lib" folder, or make a personal initialization file that augments libname.

(Perhaps someone else can confirm that "it works".)

What version of Maple are you using now?

acer

My 64bit Linux installations of Maple 2016.0 (Build ID 1113130), Maple 2016.1 (Build ID 1132667), and Maple 2016.1a (Build ID 1133417) each contain only libicuucmpl.so.56.1 (and its two associated symlinks).

Just to check I just reinstalled Maple 2016.0 to an entirely fresh new location, and then ran the 2016.1a upgrade installer obtaied from here. After the upgrade installation completes then running the commandline interface (CLI aka TTY interface) of that goes ok for me, and there kernelopts(version) reports Build ID 1133417. But for that installation I also see only libicuucmpl.so.56.1 and its two expected symlinksin its bin.X86_64_LINUX subdirectory.

So I don't quite see how your Maple 2016.1a installation could have libicuucmpl.so.49.1.1 get into it. I note that the 64bit Linux version of Maple 2015.2 had that particular binary object file. Is it possible that you somehow selected the wrong installation for upgrade?

I am running Ubuntu 14.04.4 LTS but I don't quite see how that would affect what the installer puts in place. ( I suppose that it's possible...)

If you are absolutely sure that you ran the 64bit Linux Maple 2016.1a upgrade installer against a Maple 2016.x installation location, and still see that wrong binary then I suggest you contact Technical Support.

acer

Do you mean that you want to use a concatenation of existing symbols from the current palettes, as a new symbol that can be used for both 1D plaintext input as well as typeset 2D Input (including with its own new entry say in the favorites-palette)?

acer

This is a good question.

See also this old post by John May on the topic of subexpression labelling using the mechanism that Carl cites in his Answer.

The thread of vv's Answer is also worthwhile.

acer

@mmcdara That error message likely came from an attempt to assign to L[n] or some other entry of the list.

L:=[seq(0,i=1..100)]:
L[55]:=x: # succeeds

LL:=[seq(0,i=1..101)]:
LL[55]:=x;
Error, assigning to a long list, please use Arrays

The reason the kernel does this is because lists are not really mutable objects, and one cannot assign into a list and have it use the same memory space as before. Instead. assigning into a list entry creates a new list object. It's set up so that the name to which your list is assigned (say, L) is then reassigned with the new list, and this makes it appear as if lists were mutable. But the new list must get created and the old list must be garbage collected, which can affect performance. For large lists to which entries are assigned over and over again the perfomance hit can be extreme. It's a bit awful (IMO) that the kernel allows list entry assignment even for small lists of length 100 or less, because it just fosters inefficient programming.

Basically, assigning into lists entries can be terrible for performance. As Bad Practice goes, it's right up there with repeated list/set augmentation, eg, L:=[op(L),new] .

In contrast, tables and rtables (the latter includes Array, Matrix, Vector) are mutable containers, and entries can be replaced "in place" without the container itself being made anew.

@farahnaz You need to assign to filename the correct location of the file. Change it to wherever it is on your machine. It will be different than where it is on my machine. Something like,

filename := "C:/blah/blah/blah/16.3.xlsx";

Use forward quotes in that string.

Don't forget to respond to my comments about the weird "X" data values, and clarify your intentions.

In Maple versions 10.02 through Maple 2016.1 I get a result with

ax := 1: ay := 2: a := 0.5: b := 0.25:
expr := ax*cos(lambda)+ay*sin(lambda)-(a+b*lambda):
Student:-Calculus1:-Roots(expr, lambda=-2*Pi..2*Pi, numeric);

In Maple versions 10.02 and 11.02 the attempt without the numeric option emits an error message.

And you can just apply the max and min commands to the list returned from the Roots command.

[edited to remove speed commentary, thanks Markiyan]

@Carl Love Here's a difference between ~ and map. Note the datatype of the following return values.This is with the default of Digits=10 and UseHardwareFloats=deduced. I am not sure of timing difference between map[evalhf] and ~ for float[8] rtable and an operator that is evalhf'able and/or builtin.

map[evalhf](sin, Vector(3,1,datatype=float[8])): rtable_options(%,datatype);
                                                          float[8]

map(sin, Vector(3,1,datatype=float[8])): rtable_options(%,datatype);        
                                                          anything

sin~(Vector(3,1,datatype=float[8])): rtable_options(%,datatype);            
                                                          float[8]

Note the working precision used for this arithmetic operation, though.

restart;
map(`/`,Vector([2.0],datatype=float[8]),3.0);
                                                    [0.666666666600000]

`/`~(Vector([2.0],datatype=float[8]),3.0);
                                                    [0.666666666666667]

I suspect that the Library zip command invokes the undocumented kernel builtin named rtable_zip in the following float[8] case. So I suppose that for pairs of float[8] rtables it might be used directly.

zip(arctan,Vector([1],datatype=float[8]),Vector([2],datatype=float[8]));
                                                    [0.463647609000806]

rtable_options(%,datatype);
                                                          float[8]

rtable_zip(arctan,Vector([1],datatype=float[8]),Vector([2],datatype=float[8]));
                                                    [0.463647609000806]

rtable_options(%,datatype);
                                                          float[8]

Are you saying that you can evaluate f(x,y) reasonably quickly for all of some 30x30 x-y pairs? And then you want to find the volume under the surface (by interpolating those 30x30 f values at points required by a quadrature scheme)?

Furthermore, are you saying that when you use ArrayInterpolation to set up an f-hat (which interpolates f at just a single point, on demand) that it is too slow when you pass this to evalf(Int(...))?

ArrayInterpolation doesn't necessarily set up a whole interpolation scheme each time it's called. The basic schemes are precompiled in C, and the data is used to supply the numeric coefficients required by the spline scheme. What incurs some of the overhead is creations of temporary rtables for input and output (and to get the data into the desired form). Some of that overhead can be alleviated by using module locals to get the single x-y point into the scheme, and the scalar result back, and by supplying the data in just the right form. I've found that thise can make it a bit faster, but not super quick. I can dig up an example of that from my files, later in the day.

How accurate do you need the result? Were you able to try using the epsilon accuracy option of evalf(Int(..)) in your earlier attempt, for a coarser target accuracy? Did it help? What evalf(Int(...)) method got tried, do you know?

If you have the 30x30 data points computed quickly enough, then interpolating all x-y pairs on a finer full rectangular grid is then lightning fast. If your integrand is not singular in the domain then 2D Romberg integration might suffice. That has the virtue that it only needs a rectangular grid (and when you subdivide h->h/2 then most earlier evaluations just need to get re-weighted as squares' midpoints become corners, etc). So that's a route which avoids evalf(Int(...)) altogether, but of course one has to code the 2D Romberg (and make it refine if you want an error estimate from it, and make it adaptive if you want error-estimate-based selective subdivision...).

Going back to an interpolating-on-demand procedure, if it's done really well then ideally it should be faster to handle even a lot of software float scalar x-y points separately than would evaluation of some big 2D spline piecewise thing at all those separate x-y pairs required by evalf(Int(...)). It may be possible to dig a fast implementation out of the guts of dsolve/numeric. I've been meaning to try harder at that.

Any chance we could get the whole code, so as to not have to make something up?

@mstevens Your request in bold has at least one ambiguity. You state that you want it to "display the results in a+jb or mag <angle".  If you mean that you'd want a setting that could be toggled, to switch the default return mode say, then please be clear and explicit. But otherwise what did you intend by that "or" ?

The code I wrote allows for the earlier parts of your bolded text I think. But it currently returns in mag <angle form, and conversion of  individual results to a+jb complex form require an action (which I can offer as right click menu action too). I could also add a setting for return mode.

Its important to note that there is a big difference between working with new objects at the surface level and changing how all of maple returns or prints complex values. Even changing how Maple displays all complex numeric values would be tricky because purely real values will be inherently problematic: on a case by case basis within even a single expression they might be wanted as displayed as phasor with zero angle or as pure real. Phasors containing unknown variables are also inherently problematic.

Certainly objects (in the Maple language technical sense) aren't the only way to go about this. An alternative would be to have the < influx angle operator simply evaluate directly to a+jb form, for all operations to occur as usual, and for nonreal comes numerous to optionally display in < angle form (just a display thing -- the value is still explicit complex radians). I considered that. Its doable. I did it in objects partly because i wanted to do something nontrivial in objects (that wasn't quaternion).

You are of course quite free to go your own way here.

I'm not sure if i made my view clear above, but i would really like to see Maple get in-situ or telescoping context menu functionality. I first asked for it years ago. it would serve many good uses.