@Sabeen I did not notice that your question was for Maple 12 specifically, sorry.

The `orientation` option was not an important part of my answer, as was just to make the plots display in a fixed way of my choice. You can simply remove that option from the calls, or use only two values instead of the three I used.

Here is a version revised for Maple 12.02.

inter3dM12.mw

It's not clear to me whether you really need a piecewise assembly of bivariate interpolating polynomials for your larger data sets, or whether you can make do with an (black box) interpolating function like the `f` that I have demonstrated. Note that with such an `f` you can compute at individual (x,y) points, eg. f(3.4,0.005) as well as make 3D plots.

(I don't mean to sound obtuse, but I'm not even 100% sure from your wording whether you are starting off with just arrays of numeric data, or whether you are somehow starting off with a plot structure from which you have extracted the given data. Sorry, if it should be obvious. I figured that you were starting off with a discrete regular grid of x-y points and their corresponding z-height-values, and wished to interpolate from that, eg. so as to produce a smoother 3D surface.)

If you only need to produce a more refined surface plot, and you have a very large set of numeric data (on a regular grid in the independent x-y plane) then the most efficient way to proceed in Maple 12 would likely be A) just used `surfdata` as in my sheet's first example, or B) refined to a finer mesh by manually calling ArrayInterpolation and specify the interpolatory scheme of your choice and then pass the finer mesh to `surfdata`.  Those should both be somewhat quick, depending on your GUI's rendering speed. But the second example in my attached sheet, which uses an interpolatory procedure `f` to compute values point-by-point, would be considerably slower that A) or B) for large data sets. In other words, if all you want to do is interpolate to a finer mesh, for plotting, then it's more efficient to compute the entire finer mesh in a single call to ArrayInterpolation.

See also this Example worksheet, perhaps, which has a download link at its end. Or see the ArrayInterpolation help-page.

@Sabeen I did not notice that your question was for Maple 12 specifically, sorry.

The `orientation` option was not an important part of my answer, as was just to make the plots display in a fixed way of my choice. You can simply remove that option from the calls, or use only two values instead of the three I used.

Here is a version revised for Maple 12.02.

inter3dM12.mw

It's not clear to me whether you really need a piecewise assembly of bivariate interpolating polynomials for your larger data sets, or whether you can make do with an (black box) interpolating function like the `f` that I have demonstrated. Note that with such an `f` you can compute at individual (x,y) points, eg. f(3.4,0.005) as well as make 3D plots.

(I don't mean to sound obtuse, but I'm not even 100% sure from your wording whether you are starting off with just arrays of numeric data, or whether you are somehow starting off with a plot structure from which you have extracted the given data. Sorry, if it should be obvious. I figured that you were starting off with a discrete regular grid of x-y points and their corresponding z-height-values, and wished to interpolate from that, eg. so as to produce a smoother 3D surface.)

If you only need to produce a more refined surface plot, and you have a very large set of numeric data (on a regular grid in the independent x-y plane) then the most efficient way to proceed in Maple 12 would likely be A) just used `surfdata` as in my sheet's first example, or B) refined to a finer mesh by manually calling ArrayInterpolation and specify the interpolatory scheme of your choice and then pass the finer mesh to `surfdata`.  Those should both be somewhat quick, depending on your GUI's rendering speed. But the second example in my attached sheet, which uses an interpolatory procedure `f` to compute values point-by-point, would be considerably slower that A) or B) for large data sets. In other words, if all you want to do is interpolate to a finer mesh, for plotting, then it's more efficient to compute the entire finer mesh in a single call to ArrayInterpolation.

See also this Example worksheet, perhaps, which has a download link at its end. Or see the ArrayInterpolation help-page.

@erik10 There is some introductory material on data structures in the Portal, here. It would be useful to see even more details there.

A side-by-side chart by which one could easily compare various features (mutability, uniqueness of entries, fixed or variable size, etc) of the structures might be useful for the new user.

Clear references (help links) from the list Help page to such Portal pages would be beneficial, and by that I mean more than just a "See Also" link.

A sentence indicating why a given reference is relevant can be crucial. Eg. there is a link to selection in the "See Also" section of list , and there is a brief sentence near the Examples, "To extract the contents of a list or set, use the empty selection operator [ ]." But these are too far separated. Why isn't there a help link within or adjacent to that explanatory sentence?

There should be help links to the select Help page (which includes details on `remove` and `selectremove`) on both the list Help page and that Portal page.

Using `remove` with a predicate is a common operation on lists. I don't see why that ought become a new command in the ListTools package, as long as it is more adequately referenced and illustrated by example in the Help pages of the data structures to which it applies.

1)

restart;
U := [7, 9, 14]:
A := [-2, 7, 8, 12, 9, -78, 0]:

remove(member,A,U);

                      [-2, 8, 12, -78, 0]

Someone asked about a week ago on math.stackexchange.com about your item 1) and in the answer I gave there I used something equivalent to remove(member,A,{op(U)}) because that would be more efficient in cases such as when list `U` had many entries and/or duplicates. (See also Carl's explanation below.)

acer

@PatrickT After reading your followup I'm not sure why your purposes might not be covered just by, say,

alias(gamma=__anameiwillnototherwiseuse):

@PatrickT After reading your followup I'm not sure why your purposes might not be covered just by, say,

alias(gamma=__anameiwillnototherwiseuse):

@Carl Love To me that looks like it might be an oversight in the implementation, or perhaps something difficult to get just right on the first version. It's the kind of thing that I meant when I wrote that I expect that there are wrinkles to be ironed out. I hope that this can be remedied, since it is a useful thing to want to do.

I hope that it gets fixed in the kernel. I am not trying to skirt the issue when I mention that in the Standard GUI there may be situations in which there is some minor relief in Maple 17 with the following:

restart:
local gamma;
gamma:=`γ`:
evalf(gamma); # output is prettyprinted as the lowercase Greek letter
evalf(:-gamma);

Of course, in the above the local name gamma is not unassigned. And the unevaluated instance would still evalf to the usual float value.

evalf('gamma');

                          0.5772156649

But an alias might serve a bit better.

restart:
local gamma;
alias(gamma=`γ`):
evalf(gamma); # prettyprints as the lowercase Greek letter
evalf('gamma'); # prettyprints as the lowercase Greek letter

But if using an alias is adequate for some set of purposes then why bother with the local declaration at all...

@Carl Love To me that looks like it might be an oversight in the implementation, or perhaps something difficult to get just right on the first version. It's the kind of thing that I meant when I wrote that I expect that there are wrinkles to be ironed out. I hope that this can be remedied, since it is a useful thing to want to do.

I hope that it gets fixed in the kernel. I am not trying to skirt the issue when I mention that in the Standard GUI there may be situations in which there is some minor relief in Maple 17 with the following:

restart:
local gamma;
gamma:=`γ`:
evalf(gamma); # output is prettyprinted as the lowercase Greek letter
evalf(:-gamma);

Of course, in the above the local name gamma is not unassigned. And the unevaluated instance would still evalf to the usual float value.

evalf('gamma');

                          0.5772156649

But an alias might serve a bit better.

restart:
local gamma;
alias(gamma=`γ`):
evalf(gamma); # prettyprints as the lowercase Greek letter
evalf('gamma'); # prettyprints as the lowercase Greek letter

But if using an alias is adequate for some set of purposes then why bother with the local declaration at all...

@casperyc Sorry that I accidentally made an Answer when I meant to make a Reply to Carl's Answer and examples. I was trying to show that Carl's code exhibited a bug (likely in `subs`, for Vectors).

Your original examples show that the bug does not always manifest itself. I am not sure why these next example differ in behaviour.

restart:

V:=Vector([Vector([a])]);

                                  V := [a]

lprint(V);

Vector[column](1, {1 = a}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

subs(a=5,V);

                                     [a]

restart:

V:=Vector([a]);

                                  V := [a]

lprint(V);

Vector[column](1, {1 = a}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

subs(a=5,V);

                                     [5]

@casperyc Sorry that I accidentally made an Answer when I meant to make a Reply to Carl's Answer and examples. I was trying to show that Carl's code exhibited a bug (likely in `subs`, for Vectors).

Your original examples show that the bug does not always manifest itself. I am not sure why these next example differ in behaviour.

restart:

V:=Vector([Vector([a])]);

                                  V := [a]

lprint(V);

Vector[column](1, {1 = a}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

subs(a=5,V);

                                     [a]

restart:

V:=Vector([a]);

                                  V := [a]

lprint(V);

Vector[column](1, {1 = a}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

subs(a=5,V);

                                     [5]

This is a well worded explanation of a good general approach.

The waste of resources that can occur in the case that `plot` receives an unevaluated `int` call as its first argument should not be ignored, in general. As Carl mentioned, there is a potential for a waste of resources as Maple may attempt in vain to compute the integral symbolically. But we can make some observations about when that can occur.

Such a fruitless attempt at  symbolic computation of integral can depend on the location of the dummy plotting variable within the `int` call.

If the dummy plotting veraible occurs only in the integrand then Maple may (according to the particular example) waste a very large amount of resources re-trying to compute the integral symbolically. A separate attempt at symbolic integration can occur for every substituted floating-point value of the independent dummy plotting variable.

If the dummy plotting variable occurs only in the integration range then evaluation of the `int` call at floating-point values of that variable are supposed to each trigger a reasonably quick dispatch off to evalf(Int(...)), unless a symbolic `method` is specifed. In other words int(f(x),x=a..b) should dispatch off to evalf(Int(...)) if either of `a` or `b` is a float and the other is of type realcons. This is supposed to be roughly the same as calling `int` with its `numeric` option. There may be a small overhead, above the cost of calling evalf(Int(...)) directly, but it is not supposed to be a great cost.

The first two examples below use quite similar resources (give or take fluctation seen when repeating), and both do no symbolic integration in my Maple 17.01.

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> Int(f, 0..z), -3.0..3.0)):

memory used=5.94MiB, alloc change=24.00MiB, cpu time=156.00ms, real time=160.00ms

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> int(f, 0..z), -3.0..3.0)):

memory used=6.30MiB, alloc change=24.00MiB, cpu time=172.00ms, real time=165.00ms

The next example does a small amount of symbolic integration since plot seems to pass exact -3 for x while evaluating at the left end-point.

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> int(f, 0..z), -3..3)):

memory used=27.04MiB, alloc change=28.02MiB, cpu time=530.00ms, real time=537.00ms

One other nice thing about using `Int` is that the `epsilon` tolerance of the numerical integration performed under evalf(Int(...)) can be easily relaxed, which can make some problematic examples more tractable. If the only goal is to produce a plot then high accuracy of the plotted results may not be a requirement.

acer

This is a well worded explanation of a good general approach.

The waste of resources that can occur in the case that `plot` receives an unevaluated `int` call as its first argument should not be ignored, in general. As Carl mentioned, there is a potential for a waste of resources as Maple may attempt in vain to compute the integral symbolically. But we can make some observations about when that can occur.

Such a fruitless attempt at  symbolic computation of integral can depend on the location of the dummy plotting variable within the `int` call.

If the dummy plotting veraible occurs only in the integrand then Maple may (according to the particular example) waste a very large amount of resources re-trying to compute the integral symbolically. A separate attempt at symbolic integration can occur for every substituted floating-point value of the independent dummy plotting variable.

If the dummy plotting variable occurs only in the integration range then evaluation of the `int` call at floating-point values of that variable are supposed to each trigger a reasonably quick dispatch off to evalf(Int(...)), unless a symbolic `method` is specifed. In other words int(f(x),x=a..b) should dispatch off to evalf(Int(...)) if either of `a` or `b` is a float and the other is of type realcons. This is supposed to be roughly the same as calling `int` with its `numeric` option. There may be a small overhead, above the cost of calling evalf(Int(...)) directly, but it is not supposed to be a great cost.

The first two examples below use quite similar resources (give or take fluctation seen when repeating), and both do no symbolic integration in my Maple 17.01.

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> Int(f, 0..z), -3.0..3.0)):

memory used=5.94MiB, alloc change=24.00MiB, cpu time=156.00ms, real time=160.00ms

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> int(f, 0..z), -3.0..3.0)):

memory used=6.30MiB, alloc change=24.00MiB, cpu time=172.00ms, real time=165.00ms

The next example does a small amount of symbolic integration since plot seems to pass exact -3 for x while evaluating at the left end-point.

restart:
f:= x-> exp(-exp(x^2)):
P:=CodeTools:-Usage(plot(z-> int(f, 0..z), -3..3)):

memory used=27.04MiB, alloc change=28.02MiB, cpu time=530.00ms, real time=537.00ms

One other nice thing about using `Int` is that the `epsilon` tolerance of the numerical integration performed under evalf(Int(...)) can be easily relaxed, which can make some problematic examples more tractable. If the only goal is to produce a plot then high accuracy of the plotted results may not be a requirement.

acer

This is a bug in Maple 17, illustrated by the behaviour of `subs`.

It worked properly in Maple 16.02 and at least 15.01, 14.01, and 11.02.

It works for 2-by-1 Matrices in Maple 17.01. But it is not working properly for the Vector case in Maple 17.01.

There is nothing unusual about the following way of constucting Vector V, which is similar in essence to one of your ways. It is a natural way to stack Vectors. Here it produces a (column) Vector. The `subs` action in question is broken in Maple 17.01. The problem also occurs for `eval`. It's also broken in the row-Vector analogue.

restart:
V0:=Vector([a]):
V1:=Vector([b]):

V:=Vector([V0,V1]);
                                       [a]
                                  V := [ ]
                                       [b]

P:=subs(a=5,V); # produced a Vector containing 5 in Maple 16, but is brokem in 17.01

                                       [a]
                                  P := [ ]
                                       [b]

rtable_eval(P); # this at least should work, but doesn't in Maple 17.01

                                     [a]
                                     [ ]
                                     [b]

The following constructs a 2-by-1 Matrix. It is not a more usual way of constructing a Vector (because it's a way of constructing a Matrix, rather than a Vector). The `subs` action in question is not broken in Maple 17.01, for Matrix (or Array).

restart:
V0:=Vector[row]([a]):
V1:=Vector[row]([b]):

M:=<V0,V1>;

                                       [a]
                                  M := [ ]
                                       [b]

P:=subs(a=5,M);
                                       [5]
                                  P := [ ]
                                       [b]

acer

This is a bug in Maple 17, illustrated by the behaviour of `subs`.

It worked properly in Maple 16.02 and at least 15.01, 14.01, and 11.02.

It works for 2-by-1 Matrices in Maple 17.01. But it is not working properly for the Vector case in Maple 17.01.

There is nothing unusual about the following way of constucting Vector V, which is similar in essence to one of your ways. It is a natural way to stack Vectors. Here it produces a (column) Vector. The `subs` action in question is broken in Maple 17.01. The problem also occurs for `eval`. It's also broken in the row-Vector analogue.

restart:
V0:=Vector([a]):
V1:=Vector([b]):

V:=Vector([V0,V1]);
                                       [a]
                                  V := [ ]
                                       [b]

P:=subs(a=5,V); # produced a Vector containing 5 in Maple 16, but is brokem in 17.01

                                       [a]
                                  P := [ ]
                                       [b]

rtable_eval(P); # this at least should work, but doesn't in Maple 17.01

                                     [a]
                                     [ ]
                                     [b]

The following constructs a 2-by-1 Matrix. It is not a more usual way of constructing a Vector (because it's a way of constructing a Matrix, rather than a Vector). The `subs` action in question is not broken in Maple 17.01, for Matrix (or Array).

restart:
V0:=Vector[row]([a]):
V1:=Vector[row]([b]):

M:=<V0,V1>;

                                       [a]
                                  M := [ ]
                                       [b]

P:=subs(a=5,M);
                                       [5]
                                  P := [ ]
                                       [b]

acer

Do you have the typesetting level set to `extended`? If so, then I suppose that you are seeing an enhanced prettyprinting of a call to hypergeom.

acer