22182 Reputation

29 Badges

15 years, 230 days

Social Networks and Content at

"My friend George Mallory… once did an inexplicable climb on Snowdon. He had left his pipe on a ledge, half-way down one of the Liwedd precipices, and scrambled back by a short cut to retrieve it, then up again by the same route. No one saw what route he took, but when they came to examine it the next day for official record, they found an overhang nearly all the way. By a rule of the Climbers' Club, climbs are never named in honour of their inventors, but only describe natural features. An exception was made here. The climb was recorded as follows: 'Mallory's Pipe, a variation on route 2; see adjoining map. This climb is totally impossible. It has been performed once, in failing light, by Mr G. H. L. Mallory.'." -- "Goodbye to All That", Robert Graves

MaplePrimes Activity

These are answers submitted by acer

Are you looking for something like one of these?

Or are you saying that you want the shading from your 2D image for call to complexplot3d? (It really isn't clear to me, from your Question, sorry). In that case could you simply negate the expression passed to complexplot3d? Eg,

plots:-complexplot3d(-(z - 1)/(z^2 + z + 1), z = -4 - 4*I .. 4 + 4*I
                     , style=surface, view = [-2..2,-2..2,0..2]
                     #, orientation=[-90,0,0]
                     , grid = [201, 201], shading = zhue
                     #, lightmodel=none

Do you also want contours?

You could also use printf.

Here are various ways around that problem in your old Maple 13.

(The problem relates to the presence of name r both within the indexed name P[r] and standalone, inside the radical.)

Here is a way, using freeze and thaw.  I also added an option for simplification within collect.

T := (p*a^(-Phi(xi))+q+r*a^Phi(xi))/ln(a):
u[0] := C[0]+C[1]*a^Phi(xi)+C[2]*a^(2*Phi(xi)):
u[1] := diff(u[0], xi):
d[1] := C[1]*a^Phi(xi)*T*ln(a)+2*C[2]*a^(2*Phi(xi))*T*ln(a):
u[2] := diff(d[1], xi):
d[2] := C[1]*a^Phi(xi)*T*ln(a)*(p*a^(-Phi(xi))+q+r*a^Phi(xi))
expr := expand((2*k*k)*w*beta*d[2]-(2*alpha*k*k)*d[1]-2*w*u[0]+k*u[0]*u[0]):

thaw(collect(subs(a^Phi(xi)=freeze(a^Phi(xi)), expr),
             [freeze(a^Phi(xi))], simplify@factor));

And, if you would like terms like  (a^Phi(xi))^4  to become  a^(4*Phi(xi)) ,

combine(%, power);

Depending on your metric for measuring size of an expression there are a few alternatives that can reduce the size a bit more, eg. collection w.r.t. some additional names.

There is an old problem with Optimization and "operator form" where the internal construction of the gradient procedure gets confused and produces something which merely returns zero(es). (It's a problem in the automatic differentiation.)

Some aspects of that were fixed a while back, but your example looks like it may be running into a similar problem.  (...a zero gradient confuses the algorithm into thinking that first-order conditions have been satisfied.)

Here are three workarounds. The first and second use "expression form". The first delays premature evaluation of a call to TV, using dummy variables. The second uses a slightly modification of procedure TV that returns unevaluated when passed nonnumeric arguments. The third uses a manually constructed gradient procedure that itself does numeric differentiation (via fdiff), see this old Post.


You can simply use the top-level solve command.

For example,

eqs := [ K1 = N*(R9 + R6) + R9 / (R9 + R6)*N^2 + (2*R6 + 2*R9)*N + R9,
         K2 = N*(R6 + R9) / (R6 + R9)*N^2 + (2*R6 + 2*R9)*N + R9 ]

sols := solve(eqs, [R6,R9], explicit);

One way to get something stronger than evalb (via EqualEntries, from LinearAlgebra:-Equal) is,


There are other terse ways.

The following happens due by automatic simplification in the kernel (ie. you cannot delay it using delayed evaluation, once you get to this expression):


              1  (1/2)
              - 2     

The following division does not suffer from that effect, and still using unevaluation quotes. But it is a relatively poor solution, since a pair of uneval-quotes will get stripped off upon each evaluation.



Solutions that require an ad hoc number of pairs of uneval-quotes tailored to suit the application are clumsy and poor. (Too few quotes and the effect vanishes, yet too many and ugly quotes are visible. It's a poor technique.)

There are a few other approaches that do not suffer from the ephemeral nature of uneval-quotes. One is to use an inert form:


Other choices include wrapping key parts with a call to ``(...) , which can be undone using expand or evalindets.

More work is involved if you want to replace forms in precomputed results. For example, to replace the following returned result one might sensibly wish to first check that the integer base of the radical in the numerator divides into the denominator.


              7   (1/2)
              -- 2     

But first you might want to consider whether this is for final presentation only, or whether you need computation/manipulation of the fixed-up/somehow-inertized expressions.

If you inform the identify command of additional base constant values then it can find an appropriate match.

If you provide factor with an (ad hoc, alas) extension then you can get exact trig form results without going via floating-point approximations (ie. without evalf).


Sorry, this site's not allowing me to inline the worksheet.

The SolveSteps command is part of the Student:-Basics package. It looks like you may have mistakenly tried to use the command name without either qualifying or loading it

Try either of these:

Student:-Basics:-SolveSteps([12*x + y = 18, 7*x - 8*y = 32]);
SolveSteps([12*x + y = 18, 7*x - 8*y = 32]);

Is this the kind of substitution you want to achieve? (two ways)


          = 1/(2*GAMMA(a))*(b/2)^(-a),

subsindets(ee, specfunc(anything,BesselK),

ps. I added a factor or 1/2, for fun...

The non-CUDA timing can change because the MKL bundled with Maple (ie. that matches the Intel compiler version used to build the relevant parts of Maple) can be a later version. It can change from from release to release of Maple, and Intel strives to improve it. When newer architectures arrive there may well  be additional potential optimizations which require new coding by Intel.

The CUDA implementation of the relevant DGEMM function might also be improved, over time as well as for new architectures. There's no forcing reason why the Intel MKL should improve at the same rate as the CUDA implementation.

If I correctly understand your ratio definition (and if the CUDA timing is roughly the same for your two cited Maple versions) then the diminishment in the ratio could be explained simply by the fact that Intel has improved the performance of their MKL DGEMM for at least your platform and hardware. This has been a general trend for some years now.

The cost of transfering the data to-and-from the GPU card has also become a larger relative portion of the whole computation, as the timings improve. On some platforms and architecture the MKL DGEMM on the CPU is actually faster than the CUDA DGEMM on the GPU + data transfer cost for the 4000x4000 example.

The final step can also be accomplished using the collect command.


PowerBalanceEq := 0 = e1(t) * i1(t) + e2(t) * i2(t) + e3(t) * i3(t);

0 = e1(t)*i1(t)+e2(t)*i2(t)+e3(t)*i3(t)

eq_i1 := i1(t) = solve(PowerBalanceEq, i1(t));

i1(t) = -(e2(t)*i2(t)+e3(t)*i3(t))/e1(t)

n21eq := e2(t) / e1(t) = n21;

e2(t)/e1(t) = n21

eq_i2 := algsubs(n21eq, expand(eq_i1));

i1(t) = -i2(t)*n21-e3(t)*i3(t)/e1(t)

collect(eq_i2, i2(t));

i1(t) = -i2(t)*n21-e3(t)*i3(t)/e1(t)

eq_i4 := simplify(eq_i1, {e2(t) / e1(t) = n21});

i1(t) = (-i2(t)*n21*e1(t)-e3(t)*i3(t))/e1(t)

collect(eq_i4, i2(t));

i1(t) = -i2(t)*n21-e3(t)*i3(t)/e1(t)

desired := i1(t) = -n21*i2(t) - e3(t)*i3(t)/e1(t);

i1(t) = -i2(t)*n21-e3(t)*i3(t)/e1(t)



I also adjusted your use of algsubs to obtain your intended alternate, eq_i2, which had its first argument's lhs and rhs reversed. (I recall our covering that aspect previously.)

You can get rid of the warning by explicitly declaring the name as local to the procedure.

While the 2D Input parser has not yet been updated to recognize the local declaration within a procedure entered as an operator in the arrow style, you can still enter it in the proc()...end proc way.

For example, in either 2D or 1D input modes,

    f := proc(t) local n; seq(t^n, n = 0 .. 3); end proc

or, if you'd like the immediate output of the printed procedure to appear in arrow notation,

    f := proc(t) option operator, arrow; local n; seq(t^n, n = 0 .. 3); end proc



     Maple 2020.1, X86 64 LINUX, Jun 8 2020, Build ID 1474533

4 %+ 3 %* 2;

            4 %+ (3 %* 2)

op(0,%), [ op(%) ];

            %+, [4, 3 %* 2]

In Maple 2019.2 it produced your cited result.

Several people had previously and independently reported the problem.

2 3 4 5 6 7 8 Last Page 4 of 247