Advanced Search

Rouben Rostamian

8003 Reputation

23 Badges

18 years, 161 days
Contact Rouben Rostamian

MaplePrimes Activity


These are questions asked by Rouben Rostamian

Tubeplot colors...

Rouben Rostamian 8003 Maple 2022
color linux plotting
July 19 2022
0 12

When displaying two tubeplots together, we may specify their colors at will, as long as they are different colors!  For instance, specifying red and green works correctly, but specifying red and red results in red and black!

See the attached worksheet.  Interestingly, when displaying the contents of the worksheet on this website, the colors are rendered correctly!  So don't go with what you see on this web page; look inside the worksheet instead.

> 

restart;
> 

kernelopts(version);

`Maple 2022.1, X86 64 LINUX, May 26 2022, Build ID 1619613`

> 

with(plots):

Two intersecting tori colored red and green -- works as expected:

> 

display(
        tubeplot([cos(t), 0, sin(t)], t=-Pi..Pi, radius=0.2),
        tubeplot([cos(t), sin(t), 0], t=-Pi..Pi, radius=0.2),
style=surface, color=[red,green]);

When we set both colors to red, one of the surfaces is painted black!  Why?

Please note: This website displays the colors corectly as red and red.  But

within the worksheet the colors are read and black.

> 

display(
        tubeplot([cos(t), 0, sin(t)], t=-Pi..Pi, radius=0.2),
        tubeplot([cos(t), sin(t), 0], t=-Pi..Pi, radius=0.2),
style=surface, color=[red,red]);

Specifying colors as red/red within the tubeplots still produces red/black!

> 

display(
        tubeplot([cos(t), 0, sin(t)], t=-Pi..Pi, radius=0.2, color=red),
        tubeplot([cos(t), sin(t), 0], t=-Pi..Pi, radius=0.2, color=red),
style=surface);

Download mw.mw

PS: As a workaround, we may replace the red & red specification with
COLOR(RGB, 1, 0, 0) and
COLOR(RGB, 1, 0, 0.01)
which are different enough to make Maple happy, but produce essentially the same red color.

How to have Maple solve this simple ODE?...

Rouben Rostamian 8003 Maple 2021
ode dsolve differential-equations
June 27 2022
4 5

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

Another applyrule bug?...

Rouben Rostamian 8003 Maple 2021
applyrule map elementwise
February 11 2022
1 1

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

 

A bug in applyrule?...

Rouben Rostamian 8003 Maple 2021
applyrule map elementwise
February 11 2022
3 12

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

 

Almost a rational solution to a transcen...

Rouben Rostamian 8003 Maple
September 28 2021
2 4

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?

 

2 3 4 5 6 7 8 Last Page 4 of 16