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

@Alejandro Jakubi Thanks, but ScientificConstants has several times that much infomation on isotopes. For example,

restart:
with(ScientificConstants):
select(t->evalb(op(0,t)=H),convert([GetIsotopes()],`global`));
map(GetElement,%);

I have previously found several such partial sets of data at NIST and related sites. But what is needed, I suspect, is a much more full collection which is also named (so that it can be cited and referenced for comparison at a later date).

For example, there is some mention of a 2001 published data set here, with some later update here in 2005. The 2001 data might possibly be accesible only by subscription, and the 2005 updates might possibly have its central numbers available in the linked abstract. I'd like to hear an expert's opinion.

@Carl Love Hi Carl. Darin might have a good answer for you, but I'll chip in with some anecdotal evidence if that's OK.

I was using the Task model to split (halve) some of my embarrasingly parallelizable numeric escape-time fractal code. At first I imagined that I'd get optimal performance by just using numcpus to figure out the best base case. Ie, the code could split if the "current" size were not less than 1/numcpus times the original total size.

But in practice I found that the OS (64bit Windows and 64bit Linux) could ramp up more quickly if I instead used a value higher than numcpus. Both Linux `top` and Windows' Task Manager showed all cores getting to a higher load more quickly if the Maple Task mechanism was being instructed to split more times than just the value of numcpus. Eg, on an 8-core Intel i7 or a 4-core i5 I got a measurably better total real time for the entire computation if I made the code split until the size was say 1/15th to 1/20th of the original.

I'd be interested if anyone else had seen behaviour that was similar (or radically different).

In my experience the 2010 release of the CODATA collection of values for the fundamental physical constants was easily found on the web as a single plaintext file.

I once wrote a Maple routine which processed the CODATA 2010 .txt data file and saved the data into Maple using the ScientificConstants package. This was quite straightforward a task, given the single text file with the data.

But finding the latest data for isotopes (or nuclides) in a single collection that is recognized by NIST seems more difficult. Does anyone know the location of such a data set, as plaintext or XML?

acer