Carl Love

Carl Love

28035 Reputation

25 Badges

12 years, 326 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@GFY You need to change all the initial conditions from x=0 to x=8.95. You only changed the first two.

Almost certainly you've unintentionally used gamma= 0.577..., as @mmcdara pointed out. However, my Answer still explains how to get past the singularity.

@mmcdara I believe that it would be trivial to rewrite it as a module. For example,

restart:
OrthoTable:= copy(orthopoly):
unprotect(orthopoly):
orthopoly:= module()
option package;
export 
    G:= eval(OrthoTable[:-G]), 
    H:= eval(OrthoTable[:-H]),
    L:= eval(OrthoTable[:-L]),
    P:= eval(OrthoTable[:-P]),
    T:= eval(OrthoTable[:-T]),
    U:= eval(OrthoTable[:-U])
;    
end module
:
proc(m) uses orthopoly; H(m,x) end proc(2);
                               2    
                            4 x  - 2
use orthopoly in H(2,x) end use;
                               2    
                            4 x  - 2
with(orthopoly);
                       [G, H, L, P, T, U]
H(2,x);
                               2    
                            4 x  - 2

However, for the sake of robustness, and to avoid possible backwards-compatibility issues, I think that it'd be better to name such a quick-and-dirty implementation something other than orthopoly, such as orthomodule.

Just a terminology note: Your equations are not integral equations; they're actually much simpler. Integral equations have unknown functions inside integrals. Your equations have nothing unknown inside the integrals; the only unknowns are the real-valued limits of integration. With a little bit of finesse and floating-point-error control, they should be solvable with fsolve, if they have solutions. It's my bedtime now, but I'll get back to this later today if someone else hasn't solved it yet.

@Oliver Munk Okay, then I guess that you mean that you set Windows Defender to not react to Maple, not that you turned it off completely while using Maple.

@Oliver Munk If you truly need to disable your anti-virus to stop this "freezing" problem, I don't think that that's acceptable. How about trying another anti-virus?

This isn't related to your Question. It's just a general hint for you:, You've done

pde1:= subs(case1, pde);
pde2:= subs(case1, pde1);

These would be better replaced by the single command

pde2:= eval[recurse](pde, case1);

I've found it useful to have a verifcation constructor &under just like the longstanding type constructor &under.

restart:

interface(prompt= ""):

#We model a verification constructor on this type constructor:
showstat(`type/&under`);


`type/&under` := proc(expr, theType, f)
   1   type(f(expr,_rest),theType)
end proc
 

VerifyTools:-AddVerification(
    #I'm using Maple < 2024 symbol=procedure syntax rather than Maple 2024
    #(symbol,procedure) syntax:
    `&under`= ((a,b,v::verification,f)-> verify(f(a,_rest), f(b,_rest), v))
);
#And just because I think it's ridiculous to spell out "less_than" in any
#computer code...:
VerifyTools:-AddVerification(`<`= ((a,b)-> verify(a,b,less_than)))
;

#So Austin's examples become these, reducing the need for ad hoc
#verifications such as length_not_increased:
verify(x+1/x, (x^2+1)/x, `<` &under length);

true

verify((x^2+1)/x, x+1/x, `<` &under length);

false

#Next we model the syntax e::t  =>  type(e,t) for verifications. It's not
#allowed to overload `::`, nor is `&::` allowed as an infix operator, so
#I'll settle for `&:`:
`&:`:= verify
:

#Now the examples can be written thus:
(x+1/x, (x^2+1)/x) &: (`<` &under length);

true

((x^2+1)/x, x+1/x) &: (`<` &under length);

false

 

Download VerifyUnder.mw

Could the kernel be modified so that when (a,b)::v is used in a boolean context, verify(a,b,v) would be invoked?

@Oliver Munk To check or set your Autosave status, go to Tools ==> Options from the main menu.

To load a Backup file, go to Files ==> Restore Backup.

@Exiu The best first step towards understanding a Maple data structure is to look at it with lprint, and this is often all that's needed to understand it.

lprint(f);
Sum((1/2-1/2*_alpha)/(x-_alpha),_alpha = RootOf(_Z^2+1))+Sum(1/4*_alpha/(x-
_alpha),_alpha = RootOf(_Z^2+2))

From this we see that Sum is a function (in the Maple sense), the 2nd argument of each function contains the RootOf, and the 1st argument contains the expression whose numertaor and denominator you want..

`&<`:= curry:
[op&<[2,2], [numer, denom] @ op&<1]~(indets(f, specfunc(Sum)));

 
{[RootOf(_Z^2+1), [-1+_alpha, -2*x+2*_alpha]], [RootOf(_Z^2+2), [-_alpha, -4*x+4*_alpha]]}

The command allvalues can be used to make RootOfs explicit, when it's possible to do that. Thus allvalues(f) returns the same thing as @vv 's convert(f, radical).
 

 

@mmcdara I don't know if this is true in the Maple 2015 that you use, but it has been true at least for several years: Unit is exactly the same command as Units:-Unit, regardless of whether the Units package is loaded. This just saves some typing; there's no problem with spelling out Units-Unit if you wish. I can't find documentation for this, but it can be confirmed by

restart:
eval(Unit);

               
proc () Units:-Unit(args) end proc

@DJJerome1976 

plots:-polarplot(
    4, thickness= 3, 
    coordinateview= [0..6, 0..2*Pi], axis[2]= [tickmarks= [8, subticks= 2]]
);

@Thomas Richard The help page (?Student,NumericalAnalysis,MatrixDecomposition) phrase "... using the Crout factorization algorithm for tridiagonal matrices" is poorly worded and hence a bit misleading. The Crout algorithm itself is not restricted to tridiagonal matrices; rather, the help page is trying to say that this command's implementation of that algorithm is limited to tridiagonal matrices. See the subsection "LU Crout decomposition" of the Wikipedia page "LU decomposition".

With a tiny additional step, you can convert your LDU decomposition to a Crout: Set L:= L.D. However, by using transposes as shown in my Answer, the slight extra computation of factoring the from can be avoided.

@nm For some reason that I don't understand, the assumption that the argument of ln is positive isn't enough. If you also assume _C1 < 0, it'll work.

odetest will also work for an explicit separable solution by using the right assumptions. I'm just pointing this out because it's true, not because I think the separable solution is better. I understand why the d'Alembert solution is better.

restart:

ode:= y(x) = x + 3*ln(diff(y(x), x)):

It's not necessary to use an initial condition for this. I just do it to ensure that the constant of integration

is the same in my two solutions. However, note that my initial condition is completely arbitrary.

ic:= y(x0)=y0:

ivp:= {ode, ic}:

Solution by dsolve(..., [separable]) and verification with odetest:

sol1:= dsolve(ivp, [separable]);

y(x) = -3*ln(-exp(-(1/3)*x0)+exp(-(1/3)*y0)+exp(-(1/3)*x))

assmp:= sol-> ((x,x0,y0)::~real, op(indets(sol, specfunc(ln))[]) >~ 0):

odetest(sol1, ivp) assuming assmp(sol1);

{0}

"By-hand" solution via Calc II separable technique:

eq1:= expand(eval(solve(ode, diff(y(x),x)), y(x)= y));

exp((1/3)*y)*exp(-(1/3)*x)

(ys,xs):= selectremove(has, eq1, y);
solgen:= solve(int(1/ys, y) = int(xs, x) + C, y);

exp((1/3)*y), exp(-(1/3)*x)

3*ln(-3/(-3*exp(-(1/3)*x)+C))

sol2:= (simplify@eval)(
    y(x) = solgen,
    solve({rhs(ic) = eval(solgen, x= op(lhs(ic)))}, C)
);

y(x) = 3*ln(1/(-exp(-(1/3)*x0)+exp(-(1/3)*y0)+exp(-(1/3)*x)))

odetest(sol2, ivp) assuming assmp(sol2);

{0}

Verify equivalence of solutions:

simplify(rhs(sol1-sol2)) assuming assmp(sol2), assmp(sol1);

0

 

Download DsolveSeparable.mw

@Andiguys Yes, you can include any number of inequalities in the first argument to solve. Using them has no effect on the number-of-equations-versus-number-of-variables issue. (You can't use inequalities with eliminate.) For example,

sol:= solve({tau = `&tau;opt`, lambda = `&lambda;opt`, Rem > Rom}, {w, Clm});

(`&tau;opt` is the correct way to write tauopt in 1D input (Maple Notation); I incorrectly put tauopt in the Answer above. This comment doesn't matter if you're using 2D Input, which seems to be the case.)

This type of solution (see ?solve,parametric and ?SolveTools,Parametric) very often takes a long time. The solution is returned as a piecewise structure that is often too wide to be easily read. In that case, it helps to use lprint:

lprint(sol);

The returned form will be 

piecewise(condtion[1], [solution[1]], ..., condition[n], [solution[n]], [otherwise_solution]),

where each condition is an inequality, an equation, or several such in disjunctive normal form, i.e., 

Or(And(ineq[1][1], ..., ineq[1][k[1]]), ..., And(ineq[n][1], ..., ineq[n][k[n]])),

and otherwise_solution is the solution (often empty) if all the conditions are false. Note that each solution is presented as a list, even if it's a singleton. Thus, the kth condition can be extracted via op(2*k-1, sol) and its corresponding solution via op(2*k, sol)[]. The otherwise_solution can be extracted via op(-1, sol)[].

First 13 14 15 16 17 18 19 Last Page 15 of 708