## 7766 Reputation

17 years, 357 days

## Tubeplot colors...

Maple 2022

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);

 > 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);

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?...

Maple 2021

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);

dsolve fails:

 > dsolve(de);

Attempt to solve with piecewise

 > restart;
 > de := diff(u(x),x\$2) = 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  and x>a

separately, and patch the two solutions by requiring the continuity

of  and  at .  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)));

## Another applyrule bug?...

Maple 2021

This also looks like an applyrule bug.

 > restart;
 > kernelopts(version);

 > 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)) ];

 > C := < cos(1/2*u)*sin(1/2*u), 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

## A bug in applyrule?...

Maple 2021

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

 > restart;
 > kernelopts(version);

 > half_angle_rule := [         sin(x::name) = 2*sin(x/2)*cos(x/2),         cos(x::name) = 1 - 2*sin(x/2)^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);

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);

## Almost a rational solution to a transcen...

Maple

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
﻿