Rouben Rostamian

MaplePrimes Activity


These are questions asked by Rouben Rostamian

The worksheet here shows a couple of failed attempts at coaxing Maple to calculate the general solution of a pretty simple second order ODE.  I have also included the expected solution which I  have calculated by hand.  Perhaps I am missing a key trick.  Any ideas?

The ODE that I am actually interested in is significantly more complex. The one in the worksheet is a much simplified "bare bones" specimen that exhibits the issue that I am facing.

Attempt to solve with Heaviside

restart;

de := diff(u(x),x$2) = Heaviside(x - a)*u(x);

diff(diff(u(x), x), x) = Heaviside(x-a)*u(x)

dsolve fails:

dsolve(de);

u(x) = DESol({diff(diff(_Y(x), x), x)-Heaviside(x-a)*_Y(x)}, {_Y(x)})

Attempt to solve with piecewise

restart;

de := diff(u(x),x$2) = piecewise(x < a, 0, 1)*u(x);

de := diff(u(x), x, x) = piecewise(x < a, 0, 1)*u(x)

dsolve(de);

Error, (in dsolve) give the main variable as a second argument

dsolve(de, u(x));

Error, (in dsolve) give the main variable as a second argument

 

 

The solution is easy to calculate by hand

We just solve the (quite trivial) DE over the intervals x < a and x>a

separately, and patch the two solutions by requiring the continuity

of u(x) and diff(u(x), x) at x = a.  We get

sol := piecewise(x < a,
        x*c[1] + c[2],
        ((a*c[1] + c[1] + c[2])*exp(x))/(2*exp(a)) + ((a*c[1] - c[1] + c[2])*exp(-x))/(2*exp(-a)));

sol := piecewise(x < a, x*c[1]+c[2], (a*c[1]+c[1]+c[2])*exp(x)/(2*exp(a))+(a*c[1]-c[1]+c[2])*exp(-x)/(2*exp(-a)))

Download solving-an-ode.mw

This also looks like an applyrule bug.

restart;

kernelopts(version);

`Maple 2021.2, X86 64 LINUX, Nov 23 2021, Build ID 1576349`

double_angle_rule := [
        sin(x::name/2)*cos(x::name/2) = 1/2*sin(x),
        sin(x::name/2)^2 = 1/2*(1-cos(x)),
        cos(x::name/2)^2 = 1/2*(1+cos(x))
];

[sin((1/2)*x::name)*cos((1/2)*x::name) = (1/2)*sin(x), sin((1/2)*x::name)^2 = 1/2-(1/2)*cos(x), cos((1/2)*x::name)^2 = 1/2+(1/2)*cos(x)]

C := < cos(1/2*u)*sin(1/2*u), cos(1/2*u)^2 >;

Vector(2, {(1) = cos((1/2)*u)*sin((1/2)*u), (2) = cos((1/2)*u)^2})

This application fails. Why?

applyrule~(double_angle_rule, C);

Error, dimension bounds must be the same for all container objects in an elementwise operation

Download applyrule-bug2.mw

 

This looks like a bug to me but please correct me if it is not.

restart;

kernelopts(version);

`Maple 2021.2, X86 64 LINUX, Nov 23 2021, Build ID 1576349`

half_angle_rule := [
        sin(x::name) = 2*sin(x/2)*cos(x/2),
        cos(x::name) = 1 - 2*sin(x/2)^2
];

[sin(x::name) = 2*sin((1/2)*x)*cos((1/2)*x), cos(x::name) = 1-2*sin((1/2)*x)^2]

In this example, Maple applies the rule to the first element only.
It should apply to both.

A := < sin(u), sin(u) >;
applyrule~(half_angle_rule, A);

Vector(2, {(1) = sin(u), (2) = sin(u)})

Vector[column](%id = 36893628627946684772)

In this example, Maple applies the rule to the second element only.
It should apply to both.

B := < cos(u), cos(u) >;
applyrule~(half_angle_rule, B);

Vector(2, {(1) = cos(u), (2) = cos(u)})

Vector[column](%id = 36893628627946688132)

Download applyrule-bug1.mw

 

While solving an exercise in class, I ran into the following interesting solution of a transcendental equation.  It was not intentionally designed to be like this.

restart;
eq := 2*exp(-2*t) + 4*t = 127:
fsolve(eq, t=0..infinity);
                         31.75000000

The solution looks like a rational number while it was expected to be transcendental.  Let's increase the number of digits:

Digits := 20:
fsolve(eq, t=0..infinity);
Digits := 10:
                     31.750000000000000000

Let's make it even more accurate:

Digits := 29:
fsolve(eq, t=0..infinity);
Digits := 10:
                 31.750000000000000000000000000

And even more:

Digits := 40:
fsolve(eq, t=0..infinity);
Digits := 10:
           31.74999999999999999999999999986778814353

Is there a deep reason why the solution is so close to being a rational or is it just a coincidence?

 

I may be misunderstanding the documentation of implicitplot.  Can someone set me straight?

This is extracted from the implicitplot's help page:

implicitplot(-x^2 + y, x = 0 .. 2, y = 0 .. x);

The plotting range is limited to y ≤ x, as intended.  Let us verify that it does the right thing:

display(
	implicitplot(-x^2 + y, x = 0 .. 2, y = 0 .. x, color=red),
	plot(x, x=0..2, color=blue)
);

Yes, indeed it does.

Now let us try limiting the plotting range to y ≤ 1 − x2. Here is what we get:

display(
	implicitplot(-x^2 + y, x = 0 .. 2, y = 0 .. 1-x^2, color=red),
	plot(1-x^2, x=0..2, color=blue)
);

I expected the red curve to lie entirely below the blue curve but it doesn't. Am I misunderstanding implicitplot?

Download worksheet: mw.mw

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