Carl Love

Carl Love

26513 Reputation

25 Badges

11 years, 187 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@segfault I guess that the reason that finding help for your prompt issue was difficult is that you'd likely looked for that help on pages ?DifferentialGeometry and ?DGsetup (which are quite natural places to look), but the help isn't there, because changing the prompt is a more-general operation than that package. Using ?prompt (also quite natural) will take you to the help for interface, and then you can scroll through the alphabetical list of interface settings to get to prompt.

Although it is uncommon for a stock Maple package to change the prompt, some users do do it on their own for various worksheet documenting or formatting purposes. I often change the prompt to "" (empty string) to get two extra characters of line width for code, believing that the default character styles are sufficient to distinguish among input code (red-brown boldface monospaced Courier), command output (blue Times New Roman with standard mathematical annotation), and expository text (black Times New Roman). Also, even without the prompts, there are thin brackets shown in the left margin that demarcate the execution groups. So, I personally think that having those "" all over the place is unnecessarily cluttered, and if I leave them in it's only for the benefit of less-experienced worksheet readers who may lose their place eye-tracking without them.

Some users change the prompt to "(**) ". Since that is considered a comment in Maple, stray prompts that may get copied & pasted as plain text along with the code will have no ill effect on the execution if they are subsequently copied & pasted back into Maple.

@paolam I'm guessing that you have an older version of Maple that doesn't allow local in arrow procedures and doesn't allow embedded for loops. 

Usually the best way to create a matrix is to provide a procedure which initializes its entries. The arguments of the procedure are the indices (represented by the parameters i and j in this case). (This method can be generalized to arrays with any number of dimensions.)

M:= Matrix(
    (81,24),
#need explicit dimensions for this method; parentheses are optional
    proc(i,j) local k;
        [seq](indice(C[i][1][k], rorder(orders[j], Sets[k])), k= 1..4)
    end proc
);

Procedures can be coded as proc(i,j) ... end proc or simply (i,j)-> ...; however, allowing local in these arrow expressions is a relatively recent innovation. (Arrow expressions are called lambda expressions in the functional programming community.)

The second method constructs your matrix from a list of lists of lists. The dimensions of the matrix are determined by the sizes of the outer two levels of lists, and specifying them is optional. This method is less efficient because it constructs lists that are ultimately not needed, namely the out two levels. For older Maple, it can be replaced by

M:= Matrix(
    (81,24), #optional line
    [seq](
        [seq]([seq](indice(C[i][1][k], rorder(orders[j], Sets[k])), k= 1..4), j= 1..24),
        i= 1..81
    )
);

The seq command is old command (still perfectly fine though) that's equivalent to a simple embedded for loop, which is a recent innovation. Embedded for loops are extremely flexible and just as efficient as seq, often more efficient.

You initially mentioned "table" as well as "matrix". Tables are a different container structure, and the difference between a table and a matrix is probably too subtle to be worth explaining at this point. In the code in your Question, was an unassigned variable when you first used
    M[i][j]:= ...
This caused to be a table of tables; and using instead M[i,j]:= ... would make it a one-level table. 

Finally, it's extremely inefficient to construct a list in a loop like this:
    L:= [op(L), ...]

Every newbie (including myself many years ago) seems to do this though; the idea is quite natural. The inefficiency is due to an idiosyncracy of Maple's lists known as immutability which makes then very efficient when you don't try to modify them after their initial construction. Sets and sequences are also immutable containers subject to the same inefficiency trap if you try to modify them after their initial construction. Matrices, arrays, and tables are mutable, so there's no problem with changing their entries.

You say "As f1 is 2*Pi periodic", but it isn't: f1(-1) <> f1(-1+2*Pi) 3*Pi - 2.

@nm I suspected that that was the problem when I saw the exp(n*ln(x))^2 in your result. And I also was a bit skeptical yesterday after I wrote "suitable for use in an initialization file". I considered editing that statement, but I didn't get around to it because I'm working on a better solution that is suitable. The problem with expandoff, as you've likely figured out, is that it affects internal/invisible uses of expand as well as those that you directly enter.

Your worksheet, with no modifications, gives the correct results in Maple 2023.2. The last two results are mu[1] - q and mu[1]/p.

@nm The problem with this is that the result is not a true matrix in the mathematical sense, although it is a 1x3 (not 3x3) "Matrix" in the Maple sense.

In the future, please put your questions in the Questions area rather than the Posts area.

@nm Please use your Moderator privilege to convert a Post to a Question before Answering it. If you had done this, it would've been a single item for you to convert. Since you didn't do it, that left 3 items for me to convert. So, it would've been substantially less work all around if you had done it.

@Axel Vogt It seems that simplify doesn't use evala. I wonder why.

a:= (-1)^(2/7)*(-(-1)^(3/7))^(1/2):
simplify(a);
#no change
evala(a);

             1

Maple has many commands that are dedicated to pure integer arithmetic. Most of these commands begin with i, such as iquoisqrt, and igcd shown below. These commands are much more efficient than the equivalent commands that aren't dedicated to pure integer arithmetic.

Your code can be simplified to this:

gap:= (a::realcons, b::realcons)-> sign(b-a)*(b-a) - 1:

HostsNdivisors:= proc(N::posint)
local i, d, L:= isqrt(N), P:= Array(1..0), Q:= Array(1..0);    
    for i from 3 to iquo(N,2) do
        if (d:= igcd(i,N)) > 1 then `if`(d>L, Q, P),= i fi
    od;
    P, Q, ':-gaps' = map(gap~, P, Q)  
end proc:

HostOfpq:= (p::posint, q::posint)->
local r, alpha:= iquo(q,p,r), s, t;
    [seq]([seq](gap(t*r, p*(s-t*alpha)), t= 1..iquo(p,2)), s= 1..iquo(q,2))
:
HostsNdivisors(55);
      [5, 10, 15, 20, 25], [11, 22], 
        gaps = [[5, 16], [0, 11], [3, 6], [8, 1], [13, 2]]

HostOfpq(5,11);
          [[5, 16], [0, 11], [3, 6], [8, 1], [13, 2]]

HostDiv.mw

@sand15 Your code returns the exponent of the highest power of that divides p, but the original goal was to return the quotient of that division. Of course, it's trivial to get the quotient once the exponent is known.

@Pemudahijrah01 You need to change I(t) to It(t) in the 3rd odeplot command.

@Prakash J f(0) = 0 by your initial conditions, so a plot of f(0) vs anything would just be a horizontal line. A plot of f(c) vs alpha for any constant c0 < c <= 100, is theorethically possible, but it would be a lot of work due to boundary-layer effects and convergence issues for extreme values of alpha.

@Prakash J Yes, the worksheet link in @mmcdara 's Answer is broken. His code was very likely akin to this:

eq1:= diff(f(x), x, x, x)-(1/2)*Sc*sin(alpha)*g(x)*(diff(g(x), x, x))
    +(1/2)*x*cos(alpha)*(diff(f(x), x, x))+(1/2)*sin(alpha)*f(x)*(diff(f(x), x, x)) = 0; 
eq2:= (diff(g(x), x, x, x))/Pm+(1/2)*x*cos(alpha)*(diff(g(x), x, x))
    +sin(alpha)*f(x)*(diff(g(x), x, x))-sin(alpha)*(diff(f(x), x, x))*g(x) = 0; 
eq3:= (diff(theta(x), x, x))/Pr+(1/2)*x*cos(alpha)*(diff(theta(x), x))
    +(1/2)*x*(diff(f(x), x))*(diff(theta(x), x))
    +sin(alpha)*(x*(diff(f(x), x))-f(x))*(diff(theta(x), x))
    -Nb*(diff(s(x), x))*(diff(theta(x), x))
    -Nt*(diff(theta(x), x))^2+(1/4)*Sc*Br*sin(alpha)^2*(diff(f(x), x))^2*(x*(diff(g(x), x))-g(x))
    +(diff(g(x), x))^2*(x*(diff(f(x), x))-f(x)) = 0;
eq4:= diff(s(x), x, x)+S*((1/2)*cos(alpha)*x*(diff(s(x), x))
    +(1/2)*sin(alpha)*f(x)*(diff(s(x), x)))+Nt*(diff(theta(x), x, x))/Nb = 0;

ics := f(0) = 0, (D(f))(0) = 1, g(0) = 0, (D(g))(0) = 1, theta(0) = 1, s(0) = 1;
bcs := (D(f))(100) = 0, (D(g))(100) = 0, theta(100) = 0, s(100) = 0;

params:= alpha = - Pi/6, Sc = 1.0, Pm = .1, Pr = 6.2, Nb = .1, Nt = .1, Br = .5, S = 1;

dsol:= dsolve(eval({eq||(1..4), ics, bcs}, {params}), numeric, maxmesh= 2^9);

plots:-odeplot(
    dsol, `[]`~(x, [f,g,s,theta](x)), legend= [f,g,s,theta](x),
    color= [red, green, blue, black], thickness= 3
);

 

@acer Thank you for the clarification. I should've have said that my Answer applied to the cases where there's been a reversion to adaptive= true, and that that had been made clear by your Answer.

I am disurbed by the following; I think it's a bad design decision: There now exists a "global" plot option (i.e., one that applies to a whole plot rather than to just a plot component) such that 

plot(..., OPT)

may return a substantially different result than

plots:-display(plot(...), OPT)

That OPT is axis= [mode= log]. I would prefer that this option be reserved strictly for post-processing of already computed points.

 

 

1 2 3 4 5 6 7 Last Page 1 of 689