Kitonum

21690 Reputation

26 Badges

17 years, 186 days

MaplePrimes Activity


These are replies submitted by Kitonum

@wolfman29  I understand you. I just wanted to remind that the use of polar coordinates can help solve a problem in some cases, if other methods fail (of course with Maple).

@Carl Love  Vote up. These words  "with procedural input (for more-complicated models)"- very useful remark. For some reason I had never thought about why there is a procedural input.

PS. The model also works without  initialvalues= [375, 3, -7.5]

@jamunoz  This is only an example.

Another example - a random list, a broken line on its basis, then it is made smooth by a spline:

RandomTools[Generate](list(float(range=0...10, method=uniform), 20)):

L:=zip(`[]`,[$1..20],%):

plot(L, color=red, thickness=2, scaling=constrained):

plot(CurveFitting[Spline](L, x), x=1..20, color=red, thickness=2, scaling=constrained);

                    

 

 Carl, could this example be made by means of randpoly?

 

@viraj  You are wondering why a small change in the roots  t  to lead to significant changes in value of the function  P(t) . The reason is that the derivatives of the function  P(t)  at these points is very large, i.e. graph of the function  P(t)  is very steep, almost vertical. See

Digits:=100:

P:=-12116320194738194778134937600000000*t^26+167589596741213731838990745600000000*t^24+1058345691529498270472972795904000000*t^22-4276605572538658673086219419648000000*t^20-23240154739806540070988490473472000000*t^18-5442849111209103187871341215744000000*t^16+49009931453396028716875310432256000000*t^14+74247033158233643322704589225984000000*t^12-2762178990802317464801412907008000000*t^10-25947900993773120244883450232832000000*t^8-7468990043547273070742668836864000000*t^6-567730116675454293925108383744000000*t^4+3703566799705707258760396800000000*t^2-4742330812072533924249600000000:

Sol:=fsolve(P):

seq(evalf[3](eval(diff(P,t),t=s)),s=[Sol]);  # The derivatives of P(t) at the roots

.778e50, -.206e45, .111e41, -.417e38, .224e33, -.137e33, .137e33, -.224e33, .417e38, -.111e41, .206e45, -.778e50

@viraj   

-.25965814962389295505e-49, -.39367217335124e-55, -.4842468019e-59, .1022039e-62, -.1e-68, 0., 0., -.1e-68, .1022039e-62, -.4842468019e-59, -.39367217335124e-55, -.25965814962389295505e-49

These numbers are not roots but values of the polynomial  P  in the points coinciding with found roots. As it should be, these numbers are close to zero.    

@Prof. j. smith  Remove  minimize  option, it causes an error .

An example:

Optimization:-NLPSolve(sin,-Pi..Pi, minimize);

Optimization:-NLPSolve(sin,-Pi..Pi);

 

 

 

@Markiyan Hirnyk  I do not think that your animation with  Explore  command can be easily made by  plots:-display(..., insequence)  or  plots:=animate   command. The problem is that all the frames have a coordinate system with the same ranges  (view  option does not work). See 

plots[display](seq(plot([x^2, 2*x-1], x = 1-a .. 1+a, view = [1-a .. 1+a, (1-a)^2 .. (1+a)^2]), a = 1.0 .. 0.01, -0.01), insequence);

                             

 

 

 

@one man  I quite understand you.  Alsu, vote up from me.

 

PS: Markiyan, it's interesting, but unfortunately Alsu has only  Maple 12.

@Preben Alsholm   

Unfortunately for the slightly larger number  x = 10 ^ 8 , this approach does not work:

f:=x->(1+1/x)^x;

f(10^8);

evalf(%);

             Error, (in f) numeric exception: overflow

@John_Dirichlet  Briefly, in the case  unapply(f(x), x)  then  f(x) is calculated at the time of assignment, but for  x->f(x)  at the time of calling for specific  .

Compare:

f:=unapply(diff(x^2,x), x);

g:=x->diff(x^2, x);


                                              f := x -> 2 x

                                         g := x -> diff(x^2 , x)

 

If you write  g(2)  then Maple just substitute  x=2  into uncalculated  diff(x^2, x) .  And we get  diff(4, 2) . That is syntax error because instead  2 (the second parameter)  should be a name.

Give specific examples with inverse trigonometric functions, in which you have issues. Then we will try to help you to use Maple to solve them.

@vv  Thanks for the link. Still seems a little odd that when using  evalf  command for an inert sum, by default generalized formal summation used instead of an usual summation (as the limit of the partial sums).

@Kitonum   with a large number of lines. The arrow was made in Paint:

R := evalc(1/(1-x-I*y)):

R1 := op(1, R), coeff(R, I):

f := unapply([R1], x, y):

F := plottools[transform](f):

A := plot([seq([convert(<cos(1/8*Pi*i), -sin(1/8*Pi*i); sin(1/8*Pi*i), cos(1/8*Pi*i)> . <t, 0>, list)[], t = -.95 .. .95], i = 0 .. 15), seq([r*cos(t), r*sin(t), t = 0 .. 2*Pi], r = 0.1 .. 0.95, 0.085)], color = red, thickness = 0, view = [-1 .. 1, -1 .. 1], numpoints = 1000, view = [-3.5 .. 3.5, -3.5 .. 3.5]):

B := plots[display](F(A), view = [0 .. 7.5, -3.5 .. 3.5]):

plots[display](<A | B>, scaling = constrained, axes = box);

 

 

 

 

 

@Carl Love  Thank you for your helpful comment. I had never thought about the possibility of adjusting the thickness of the gridlines. Especially I like monochrome color with thin gridlines:

y := 0: z := 0:

plot3d(abs((2*(-exp(-t-x-z)+exp(t+x+z)))/(exp(-t-x-z)+tanh((1+I)*t+(1/2-1/2*I)*y+z)+exp(t+x+z))), x = -5 .. 5, t = -5 .. 5, color = khaki, thickness = 0, axes = normal, orientation = [15, 50], numpoints = 20000);

                        

 

 

@mskalsi  I do not know how to explain this effect.

First 77 78 79 80 81 82 83 Last Page 79 of 133