dharr

Dr. David Harrington

7720 Reputation

22 Badges

20 years, 237 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

Maple Application Center
I am a retired professor of chemistry at the University of Victoria, BC, Canada. My research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity


These are replies submitted by dharr

@Christian Wolinski I sumitted an SCR.

Use the green up-arrow to upload the worksheet.

@tomleslie @mmcdara Well, @nm asked for "a more elegent way to remove any entry in piecewise which has undefined in it". I didn't really answer that for the general case, but did for the case in question with a Heaviside function. As always, Maple considers the general case and one needs to be careful in special cases. I'm sure @nm will consider that. However, in the context of laplace transforms outputting the unit step function is fine because integrals are involved. In fact taking the Laplace transform of the different outputs gives the same answer:

restart;

with(inttrans):
expr:=exp(-s)/s;
t1:=invlaplace(expr,s,t);
p1:=convert(t1,piecewise);
_EnvUseHeavisideAsUnitStep:=true;
p2:=convert(t1,piecewise);
laplace(t1,t,s);
laplace(p1,t,s);
laplace(p2,t,s);

expr := exp(-s)/s

t1 := Heaviside(t-1)

p1 := piecewise(t < 1, 0, t = 1, undefined, 1 < t, 1)

_EnvUseHeavisideAsUnitStep := true

piecewise(t < 1, 0, 1 <= t, 1)

exp(-s)/s

exp(-s)/s

exp(-s)/s

 

Download Heaviside.mw

For the general case, Maple straddles the two extremes of treating Heaviside as a function or a distribution, and so for other applications I agree the unit step function might not be appropriate.

@Rouben Rostamian  In Maple 2022, ?coords takes me to a very helpful page "Coordinate Systems Supported in Maple" which makes this clear. (This page wasn't so easy to find in the online help.):

"(**): There are two widely used conventions for how to represent spherical coordinates: one is used more in physics and the other more in mathematics. The only difference is a swap of the second and third coordinate: the vector represented by 
                           "u, v, w"

 in one convention is represented by 
                           "u, w, v"

 in the other. The plotting library, the changecoords command, and the VectorCalculus package allow you to use the coordinate system names spherical_math and spherical_physics to refer to these coordinate systems unambiguously. You can also use the name spherical; its behavior is as follows:
– If neither of the Physics and VectorCalculus packages has been loaded (using the with command), then the plotting library and the changecoords command will interpret spherical as spherical_math.
– If either of the packages Physics or VectorCalculus has been loaded, then the plotting library and the changecoords command will interpret spherical as spherical_physics.
The VectorCalculus package will always interpret spherical as spherical_physics.
 

@Ahmed111 Well, Maple is often a bit inscrutable about the way it does things. Here's my guess. The first time, Maple always found the lambdas together, e.g., (lambda__1-conjugate(lambda__2)) and so kept them together. But the second time, you have things like phi2 or conjugate(psi2), which now have polynomials in lambda__2 or its conjugate. Now I might look at phi2 and conjugate(psi2) and try to combine them (they are very similar after all, but not conjugates), which might give a shorter expression if split into real and imaginary parts.

If you don't want Maple to combine them, just call them something like lambda__1 and clambda__1 until the end of the calculation and then substitute back.

But at some point, you have to decide what is acceptably simple, and Maple might not agree (or at least without contortions).

@arashghgood You needed list1[i][2] instead of just list1[i], and numeric rather than numerical.

ode.mw

@arashghgood I'm confused about what you want. You talked about residues - do you want to do a contour integration? if so of what function - Q, deq? - which contour? upper half plane? That can probably be done.

How exactly was the plot in c made? I think by numerical solution of the same differential equation? if you want to exactly replicate that then it would be helpful to know the method, stepsize, hardware precision, exact initial conditions.

Perhaps a step back to tell us where is problem came from and what you want out of it would be helpful.

@arashghgood You can try stiff methods other than the default resenbrock one, e.g. lsode. You could put Digits higher for more accuracy, but it will get very slow. In combination with the transformation method to add a small imaginary part you may get closer to what you want. I don't really understand what you are expecting - near a sigularity inaccuracy seems inevitable.

@arashghgood Stiff method seems to work here, without transformation. (just plotting real and imm parts of Q)

Download ODE.mw

Edit: at least for the second case. For the first, it varies depending on the exact values of the ic.

@arashghgood  The dchange can be done more simply by 

ode2:=PDEtools:-dchange({K=x+a},ode,[x],params=[a]):

and still using Q. Result is the same. Hard to understand any discrepancy.

@arashghgood Perhaps you can reformulate, e.g., K=x+a with x real (including changing the derivatives appropriately). PDEtools:-dchange can do a change of variables - see attached. But ignoring singularities seems risky.

Download ODE.mw

@Thomas Dean Here's my interpretation. The wikipedia page you cited makes clear  is the notation for a ring, modulo n. So for the additive group modulo n, the order is n, but for the multiplicative group, 0 is excluded and the order is n-1. So your ord=12, mod 13, is Z/13Z.

This is how you used it in your original post.

@Thomas Dean Your original table didn't have 0 in the multiplicative case, so I emulated that without thinking too much about it. The Wikipedia page talks about integers 0..n-1 mod n. So that may be part of it. But notice that you are doing ord=12, which is mod 13, which is prime. If you change ord to 11, so mod 12, you get an error message, since the default is to check that it is a group. Try other values, some work and some don't.

@Thomas Dean 

restart

with(GroupTheory)

Matrix has to have the entries coded as 1..4

v := [1, -1, I, -I]; M := Matrix(4, 4, proc (i, j) options operator, arrow; eval(v[i]*v[j], `~`[`=`](v, [`$`(1 .. 4)])) end proc)

v := [1, -1, I, -I]

Matrix(%id = 36893490351220485524)

G := CayleyTableGroup(M)

_m2203734088608

CayleyTable(G)

Array(%id = 36893490351220474092)

lbl := proc (i) options operator, arrow; v[i] end proc

proc (i) options operator, arrow; v[i] end proc

DrawCayleyTable(G, labels = lbl)

NULL

Download Group.mw

First 41 42 43 44 45 46 47 Last Page 43 of 78