acer

26592 Reputation

29 Badges

17 years, 0 days

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

You could try renaming your .mw worksheet with a file-name that doesn't include special characters (`+`, "(), etc). Try it with only alpha-numeric characters, underscores, and a period.

Some special characters can confuse the backend of this forum, preventing downloads.

@Carl Love Does your Windows Task Manager show a similar CPU load if the option engine=triade is used instead?

@MaPal93 It is counter-productive and unnecessarily difficult for the readership if a derivative followup query is separated from its parent, since that obscures connections amongst the information and details given by the original poster as well as the responders.

@Carl Love Despite the wording of the error message I don't see that the sign command is necessarily the problem here.

I'd guess that signum is being used at some internal juncture, and the calling routine is not properly prepared to deal with its result...

@MaPal93 Please do not put that followup in a (duplicate) separate Question thread.

How would you feel about taking limits instead of using eval? Or do you want to know precisely how dsolve's internals are handling it differently?

note: in Maple 2017.3 (and 2022.1) a single call to limit can do the same.

restart

kernelopts(version);

`Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895`

sys_1 := {diff(x(t), t$2)=sin(t)-x(t), x(0)=0, D(x)(0)=0}:

sol_1 := dsolve(sys_1);

x(t) = (1/2)*sin(t)-(1/2)*cos(t)*t

sys_2 := {(M__p+M__a)*diff(x(t), t$2)=M__p*sin(t)-x(t), x(0)=0, D(x)(0)=0}:
sol_2 := dsolve(sys_2)

x(t) = sin(t/(M__p+M__a)^(1/2))*M__p*(M__p+M__a)^(1/2)/(M__p+M__a-1)-M__p*sin(t)/(M__p+M__a-1)

limit(eval(sol_2, M__p=1), M__a=0);

x(t) = (1/2)*sin(t)-(1/2)*cos(t)*t

limit(eval(sol_2, [M__a=0]), M__p=1);

x(t) = (1/2)*sin(t)-(1/2)*cos(t)*t

Download SomethingWrong_ac.mw

Shout if you have reservations.

@jalal Here is my suggestion for 2D math in the "headers" together with Carl's suggestion for additional substitution of complex values.

DocumentTools:-Tabulate(subsindets[flat](
                          Matrix([<["",F(x)[]]>,
                                  ((Vector@[u->u,F[]])~(C))[]]),
                          {undefined,And(complexcons,Not(realcons))},
                          ()->dne),
                        width=50,
                        fillcolor=((T,i,jj)->`if`(i=1 or jj=1,
                                                  [210,230,255],
                                                  [255,255,235]))):

You could put that into a reusable procedure, if you'd like, which could be hidden in a document's Startup code or a collapsed Code-Edit-Region. Such a procedure could simply take F and C as its arguments.

@jalal You could instead use a Matrix for the whole thing, with data and headers together, to get the header expressions to render in pretty-printed 2-D math.

DocumentTools:-Tabulate(subs(undefined=dne,
                             Matrix([<["",F(x)[]]>,
                                     ((Vector@[u->u,F[]])~(C))[]])),
                        width=50,
                        fillcolor=((T,i,jj)->`if`(i=1 or jj=1,
                                                  [210,230,255],
                                                  [255,255,235]))):

That summation index variable n1 is not entirely like the variable n. That name n1 represents a bound variable, since your sum call denotes that it would only take integer values between 1 and n-1.

There's not much significant difference between using the name n1 instead of the name i, or what have you. For example, these next two are conceptually similar:

    sum(f(i), i = 1 .. n-1)
    sum(f(n1), n1 = 1 .. n-1)

The end result of both of those would usually be the same; the results depend on (any value of) n in the upper end-point of the index, but the results don't depend on which choice of name is used for the summation index.

Maple knows a bit of that, which can be useful:

depends(sum(f(n1),n1=1..n-1), n);

         true

depends(sum(f(n1),n1=1..n-1), n1);

         false

depends(sum(f(i),i=1..n-1), i);

         false

expr := sum(f(i),i=1..n-1):

indets(expr, And(name,
                 satisfies(nm->depends(expr,nm))));

          {n}

@David Mazziotti Maple's GUI renders a certain kind of markup for its 2D Math pretty-printing, a.k.a. typesetting. There is a strong resemblance to MathML. The Maple specifics are not user-documented.

The "mo" stands for math-operator, and "mi" for math-identifier. (See here, for similar details.)

It can come in two forms. One construction consists of specially formed names, and the other of special function calls using exports of the Typesetting module. For example,

This first is all one long name.

`#mrow(mi("a",mathcolor="FF00BB"),msub(mi("x"),mi("i")))`;

`#mrow(mi("a",mathcolor="FF00BB"),msub(mi("x"),mi("i")))`

This next consists of nested function calls.

Typesetting:-mrow(mi("a",mathcolor="FF00BB"),
                  Typesetting:-msub(Typesetting:-mi("x"),
                                    Typesetting:-mi("i")));

a*x[i]

Download typemkex.mw

It can be very handy to be able to programmatically construct things which print in special ways (including the case where there is no usual Maple structure that would normally print in that manner).

Quite often one can infer how these forms work by creating some 2D Input, then using the right-click context-menu item,
   2-D Math -> Convert To -> Atomic Variable
and then executing, and then calling lprint on the result to show its structure.

See also the results of,
   exports(Typesetting);
which are mostly undocumented.

@MalakMMK I don't think that you coded the formula from the Hafiz paper correctly; at least some brackets are missing.

For example you had, as the first step,
   u - (2*F(u)/3*dF(u))
but the paper shows the denominator of that as all of 3*dF(u), hence,
   u - 2*F(u)/(3*dF(u))
Also, you had,
   v - F(u)*W/dF(u)+dF(v)
but the paper show the denominator of that as all of dF(u)+dF(v), hence,
   v - F(u)*W/(dF(u)+dF(v))

The paper defines "eta = f'(x)/f'(y) without the index n", which seems a little confusing. Below I used eta := dF(u)/dF(v) and get apparent success. Please edit and explain, if you think that's wrong.

[edit: Below I used a value of 20 for the maximal iteration cutoff, ie the third argument passed to H. So for a sensible comparison with the earlier Newton's and King's methods you might want to re-run those with that same value.]

Haf_Newton_ac1.mw

 

@Sradharam In the original example pde was assigned an equation, ie, something=0. That's why I used lhs(pde).

In your followup worksheet pde is no longer assigned as an equation. So the lhs call is no longer needed.

How_to_collects_the_coefficents_ac.mw

Please stop putting additional details and followup queries for this in new and separate Question threads.

Instead, you can add your additional details and followup queries for this here.

Please put your followup queries and additional details or attempts for this problem in a Reply/Comment in this same Question thread, instead of spawning a separate and new Question thread.

@Dkunb What is the significance of the curve separating the red and gray areas in the plot on the left? Is it supposed to denote a contour (level curve) of value of N(beta,alpha)?

If that is so then what is the common value that N attains along that contour? If that is not so then what does that curve represent?

ps. I'm trying to figure out what's going on with the alpha range, ie. any discrepency.

[edit: As alpha and beta get large (but especially as alpha gets large) the surface becomes relatively much flatter, which might confuse some commands or approaches for attaining a nice, smooth contour near N(beta,alpha)=0. It's possible that implicitplot might handle that better...]

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