Carl Love

Carl Love

26668 Reputation

25 Badges

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

MaplePrimes Activity

These are answers submitted by Carl Love

It can be done with a single plot command. No transform or display is needed.

V:= exp(-x)*y^3/eta^3:
eta:= 1+k*x+sin(2*Pi*x):
x:= 0.1:
Ks:= [.1, .5, -.1]:
     [seq](eval([V, y, y= 0..eta], k= K), K= Ks),
     labels= ["v", "y"],
     color= [black, red, blue],
     linestyle= [solid, dash, dot],
     legend= [seq](k = K, K= Ks)

It is sad that you have not received more help.... I can give you a tiny bit of help, but I have very little knowledge of this subject area. I think that some of what you want can be done with the ?DynamicSystems package. In particular, there is ?DynamicSystems,BodePlot and ?DynamicSystems,TransferFunction .

I think that Joe Riel may know this package well. Maybe he will notice this namecheck and respond.

Also, could you please retype your expressions in normal characters? The Maple Math typesetting is horrible---nearly impossible to read.

Since no-one has answered yet and I know at least part of the answer, I will try to give some help. But I don't know much about Maplets yet.

What I can tell you for certain: Unlike some other languages (such as C), Maple does not allow assignments (:=) to be embedded in expressions. By changing a comma (,) to a semicolon (;), your code above can be made syntactically correct:



      [CheckBox['CB1'](), "Box1"],

      ....for all 6 boxes...

])); #<-- Here's the change

lstW:=['CB1','CB2',...for all 6 boxes];

What I'm not sure about: While the above is syntactically correct, I don't know whether it does anything useful.



A plot of the function that you call pdf clearly shows that it is not a p.d.f. Its horizontal asymptotes are at e, not 0. Thus CDF is meaningless.  Also note that the result returned by dsolve has the form f(x) = ..., so, if the concept were meaningful at all, you'd need to have rhs(pdf) where you currently just have pdf.

Your X25 and X2 are Vectors of polynomials. Quotient does not take Vectors as arguments, but it will take polynomials. So you could do

Quotient(X25[2], X2[2]);

Come up with some other name for the imaginary unit. Let's say you choose i (but it does not need to be a single letter). Then do

interface(imaginaryunit= i);

Then you're free to use I however you want.

In Maple 17, all you need to do is

local I;

and that will automatically change the imaginary unit to _I.

The solution returned by dsolve is taking a long time to compute plot points because non-numeric dsolve computes symbolic solutions in exact arithmetic even when the input coefficients are floats. This can lead to some extremely large rational numbers in the solution. (You can override this default with dsolve(..., convert_to_exact= false).) In this case, the solution is of the form exp(Int(N/D^2)) where the integral is unevaluated, N is polynomial of degree 8, D is polynomial of degree 5, and the coefficients of each polynomial are integers each having several hundred digits. When you try to plot this solution, Maple attempts a numerical integration (quadrature) of the exponent for each plotted point. For most of those points, it gives up because it can not achieve the accuracy specified by your value of Digits (probably set at the default 10).

It may be possible to carefully adjust the digits (lowercase d) and epsilon options on the numeric integration (see ?evalf,Int ) so that a plot can be obtained in a reasonable time. But it is much easier and much more efficient to use dsolve(..., numeric) and odeplot, like this:

pdf := dsolve(motion union ic, numeric);

plots:-odeplot(pdf, x= -0.01..0.01);

When you see the plot, you'll know why I chose such a narrow range.

The above Answers assume that the integral is real as if that were obvious. Perhaps it is obvious to some, but it wasn't to me. So here's a proof that it is real.


J:= exp(I*epsilon*ln((2+t)/(2-t)))*exp(I*n*t)/sqrt(4-t^2)/Pi;


plot(eval(Im(J), [epsilon= -0.4, n= 1]), t= -2..2);

The imaginary part appears to be an odd function of t. That would make the integral over a symmetric real interval real. Let's prove it's an odd function.

evalc(Im(J)) assuming t::RealRange(-2,2);




ImJ:= unapply(%, t):

simplify(ImJ(t)+ImJ(-t)) assuming epsilon::real, n::real, t::RealRange(-2,2);


Therefore the imaginary part of the integrand is an odd function of t (for real n and epsilon).



Why use such a crude trial-and-error method to find the B for each A? Here's a way using Optimization:-Minimize:

for k to 300 do
     A:= .01*k;
     Bmin:= Optimization:-Minimize(
          B, {exp(B)-A-1 >= 0, exp(B)-A/2-1.5 >= 0},
          feasibilitytolerance= 1e-6, optimalitytolerance= 1e-6,
          initialpoint= {B= .1}
     Sol[k]:= [A,Bmin]
end do:
plot(convert(Sol,list), labels= ['A', B[min]]);

Or we can get a fully symbolic solution thus:
L1:= solve(exp(B)-A-1, B);
                           ln(A + 1)
L2:= solve(exp(B)-A/2-3/2, B);
                            /1     3\
                          ln|- A + -|
                            \2     2/
convert(max(L1,L2), piecewise) assuming A>0;
                 /          /1     3\                  \
        piecewise|A <= 1, ln|- A + -|, 1 < A, ln(A + 1)|
                 \          \2     2/                  /

We can give this problem a more sophisticated combinatorial treatment. This might be appropriate for a case where the number of permutations is so great that iterating through them is undesirable. We note that any permutation of the four fractions in any solution is also a solution, essentially the same. Thus we can reduce the search by a factor of 4! = 24. The following returns the 8 unique solutions ((Kitonum's 192) / 4!) in 0.343 secs.

eq:= add(a[k]/a[k+4], k= 1..4) = a[9]:
S:= {$1..9}:
Sols:= table():

for s in S do
     S1:= S minus {s};
     for C in combinat:-choose(S1,4) do
          C1:= S1 minus C;
          for P in combinat:-permute([C1[]]) do
               A:= [C[],P[],s];
               if evalb(eval(eq, a= A)) then
                    Sols[A]:= [][]
               end if
          end do
     end do
end do:
for Sol in indices(Sols, nolist) do
   print(eval(eq, a= ``~(Sol)))
end do;

                  (2)   (3)   (5)   (7)      
                  --- + --- + --- + --- = (9)
                  (8)   (6)   (4)   (1) 

                  (1)   (4)   (6)   (7)      
                  --- + --- + --- + --- = (5)
                  (3)   (8)   (9)   (2)  

                  (3)   (5)   (6)   (7)      
                  --- + --- + --- + --- = (9)
                  (2)   (1)   (8)   (4)   

                  (3)   (4)   (5)   (7)      
                  --- + --- + --- + --- = (8)
                  (9)   (1)   (2)   (6)   

                  (2)   (4)   (5)   (7)      
                  --- + --- + --- + --- = (9)
                  (3)   (8)   (6)   (1) 

                  (2)   (5)   (6)   (9)      
                  --- + --- + --- + --- = (7)
                  (1)   (4)   (8)   (3)  

                  (2)   (5)   (6)   (7)      
                  --- + --- + --- + --- = (9)
                  (8)   (1)   (3)   (4)    

                  (1)   (2)   (7)   (9)      
                  --- + --- + --- + --- = (5)
                  (6)   (8)   (3)   (4)      


First, get rid of with(linalg). Then replace these old linalg commands

with the single command

Solution:= LinearSolve(A, XY):

Then you can plot the exact and the approximate solution together with

F:= x-> (1-x)*cos(x):
     pointplot([seq]([h*(k-2), Solution[k]], k= 2..m+1), color= blue),
     plot(F(x), x= 0..1)
], symbol= diamond

You can plot the errors with

     [seq]([h*(k-2), F(h*(k-2)) - Solution[k]], k= 2..m+1),
     symbol= cross, title= "Errors"

You need to use lists rather than sets because you have no control over the order that things will appear in a set. Also, your indices themselves need to be lists because "naked" sequences cannot be distinct members of lists (or sets). Once you have lists, let's say A is your list of indices and B is the set of values. Then just do

A =~ B

It is possible for a naked sequence to be either or both of the sides of an equation. You can achieve this by

zip((x,y)-> op(x)=y, A, B)

zip is the two-set (or two-list) analog of map that you were looking for.


A:= [[1,2], [3,4]]:
B:= [5,6]:
zip((x,y)-> op(x)=y, A,B);
                    [(1, 2) = 5, (3, 4) = 6]

There is no effective way to make such an assumption. Even if you were include every possible inequation x[i] <> x[j], you would likely just overload the ability of a solver. That's why Combinatorial Optimization and Constraint Satisfaction Problems are their own areas of study, distinct from, for example, Linear Programming.

But you can solve such an equation by cycling through all permutations if the number is not too great. In the case at hand, we have 9! ~ 300,000---reasonable. The following executes in 0.235 secs for me.

eq:= a[9] = add(a[2*k-1]/a[2*k], k= 1..4):
A:= combinat:-firstperm(9):
while not evalb(eval(eq, a= A)) do  A:= combinat:-nextperm(A)  od:
eval(eq, a= ``~(A));

I tried in both Maple 16 and 17, and I cannot duplicate your results; I get relatively smooth plots for the first and second derivative. According to ?dsolve,numeric,bvp , the maximum value of maxmesh is 2^13 = 8192. I got results at 2^10, with no difference at 2^13. I decreased abserr to 1e-7 (default is 1e-6) and increased Digits to 20, and I got no difference. Here are my plots. Note that the range is 0..1.

for k from 0 to 2 do
     odeplot(sol, [x, diff(Urn(x), [x$k])], 0..1, numpoints= 1000)
end do;

You wrote:

Also, the list with the output does not show the 2nd derivative of Uthetan, the 4th derivative of Urn and the 2nd derivative of Uxn. They are in the equations... is that a problem?

It is not a problem. It never includes the highest-order derivative of any of the functions. If you want to plot those derivatives, there are several workarounds.

I tried in both Maple 16 & 17, obtaining the same results. The "hang" occurs in simplify. I don't know whether it is an infinite loop, or just an expression that is too complicated for simplify. Since the expression fits on one line on my screen, the latter seems unlikely. Running with infolevel[simplify]:= 5, the only information is a seemingly endless repetition of

  • simplify/do: applying  commonpow  function to expression
  • simplify/do: applying   power  function to expression

The hang will occur for any of z[17], z[18], z[19], z[20]. It does not matter whether the expand or factor or both are applied before the simplify. Only the first two solutions need to be substituted in for the hang to occur. So here is one of the seemingly simple expressions for which it hangs:

subs(solution1, solution2, z[20]);



0 = -(-b4*f8+b8*f4)*conjugate(f7)*d5*(conjugate(b4)*conjugate(d8)-conjugate(b8)*conjugate(d4))/((a4*b8-a8*b4)*(conjugate(a4*b8)-conjugate(a8*b4)))-(-a4*f8+a8*f4)*conjugate(f7)*d5*(conjugate(a4)*conjugate(d8)-conjugate(a8)*conjugate(d4))/((a4*b8-a8*b4)*(conjugate(a4*b8)-conjugate(a8*b4)))+conjugate(e7)*e5



First 353 354 355 356 357 358 359 Last Page 355 of 384