## 884 Reputation

15 years, 214 days

## dsdt...

@Carl Love That sounds confused. Clarification:

`D[1, 2](1/x)(s, t)` means `diff(1/x(s,t), s, t)`. D[1,2] means first derivative in first coordinate, first derivative in second coordinate. Your expression `D[1, 2](1/x);` implies x is a function of 2 coordinates.

@Carl Love Edit:
Observing Maple 5.4 I asserted you were correct. This was already implemented in Maple. Here is a demonstration for Maple 5.4 (it does not work in Maple 2017):

```restart;
constants := constants, '_EnvConstants';
S := {x^2 + y^2 - 1};

proc()
_EnvConstants := x;
solve(S);
end();

proc()
_EnvConstants := y;
solve(S);
end();

proc()
_EnvConstants := NULL;
solve(S);
end();
```

Above code does not give desired output in Maple 2017. Here is a poor improvisation:

```restart;
_EnvConstants:=:-constants;

S := {x^2 + y^2 - 1};

proc()
:-constants:=_EnvConstants, x;
solve(S);
end();
:-constants:=_EnvConstants:

proc()
:-constants:=_EnvConstants, y;
solve(S);
end();
:-constants:=_EnvConstants:

proc()
:-constants:=_EnvConstants;
solve(S);
end();
:-constants:=_EnvConstants:

```

## Consider solvers....

@Carl Love Constants are not treated as variables by solvers. One way to consider different interpretations of a problem is to redeclare constants. It is a sensitive task. An envvar is precisely intended to deal with this situation. Within the scope of a procedure anything can be done with it. Let us consider an envvar that extends the global constants, so that constants are those found in: constants, EnvConstants.

## Void....

@acer I think you are misinformed. I made a followup response in that question thread and I then made a post with the same statement I used. Someone has deleted that post and modified the question thread into a post (to take place of the one I created). When I saw this doubt arose in me, for if I change the post back into a question it may be changed yet again. I voided this problem by deleting the whole thing. I reserve "posts" for presentations/factual data and "questions" for queries.

Do we know who was acting here?

## Gone....

@Christopher2222 Well after I reposted someone deleted it again. I dont care this much to put up with this.

## Saved....

@Christopher2222 I think I still have a copy&paste of it. I'll repost today.

## I do not know....

Someone deleted my post and then converted my question into a post to replace it. I deleted the new post. My apologies.

## Limitless....

@Rouben Rostamian  You wish for what once was, as do I. Maple 5.4 had an arbitrary amount of sources of light. I never checked limits for it. I imagine their new interface coerced this change. Lame.

## Buggy lights....

@Carl Love I just found this online, quite randomly since I gave up on this issue.

From Maple Help page:

Lighting Schemes

 No Lighting displays the surface as though no colored lights were shining on it.
 User Lighting displays the surface with a user-defined lighting scheme that was defined with the light option in the plot command that created the plot.
 Light Scheme 1 displays the surface with three directional light coordinates: (90.0, -45.0, 0.0, 0.9, 0.0), (-45.0, 45.0, 0.0, 0.0, 0.9), and (45.0, 90.0, 0.9, 0.0, 0.0). To interpret these coordinates, see plot3d/options.
 Light Scheme 2 displays the surface with three directional light coordinates: (90.0, 45.0, 0.9, 0.0, 0.0), (45.0, 45.0, 0.0, 0.9, 0.0), and (-45.0, 90.0, 0.0, 0.0, 0.9).
 Light Scheme 3 displays the surface with three directional light coordinates: (45.0, 45.0, 0.0, 0.0, 0.9), (45.0, 45.0, 0.0, 0.9, 0.0), and (135.0, 0.0, 0.9, 0.0, 0.0).
 Light Scheme 4 displays the surface with one directional light at coordinate: (60.0, 85.0, 0.8, 0.8, 0.8).

I tried again with Maple 5.4 and Maple 2017. Result is clear: Maple 2017 render is bugged.
Some observations:
1) only the last light in the sequence of lights is applied to the object
2) the condition persists when using DAG objects.

```L:=[[(45.0, 45.0, 0.0, 0.0, 0.9)],[(45.0, 45.0, 0.0, 0.9, 0.0)], [(135.0, 0.0, 0.9, 0.0, 0.0)]]; plot3d(1, alpha = 0 .. 2*Pi, beta = 0 .. Pi, coords = spherical, color = white, style = patchnogrid, view = [(-2 .. 2)\$3], axes = boxed, scaling=constrained, grid=[81,41], light=L[1], light=L[2], light=L[3],ambientlight=[0.5,0.5,0.5]); plot3d(1, alpha = 0 .. 2*Pi, beta = 0 .. Pi, coords = spherical, color = white, style = patchnogrid, view = [(-2 .. 2)\$3], axes = boxed, scaling=constrained, grid=[81,41], lightmodel=light3);```

Maple 5.4:

Maple 2017:

@Carl Love So that is the difference. They removed colors from light models. How pathetic.

## Different Maple versions....

@Carl Love Forgot to label these. First one is Maple 2017, second one is Maple 5.4. My apologies.

## Some visuals:...

Maple 2017.

plot3d(1, alpha = 0 .. 2*Pi, beta = 0 .. Pi, coords = spherical, color = white, lightmodel = light3, style = patchnogrid, view = [(-2 .. 2)\$3], axes = boxed, scaling=constrained, grid=[81,41]);

Maple 5.4

plot3d(1, alpha = 0 .. 2*Pi, beta = 0 .. Pi, coords = spherical, color = white, lightmodel = light3, style = patchnogrid, view = [(-2 .. 2)\$3], axes = boxed, scaling=constrained, grid=[81,41]);

## The problem is there,...

@Carl Love I see what you see. I still believe this is all wrong. Why can I not induce color? I recall lightmodel being much more useful than this.

```plot3d(0, 0..1, 0..1, glossiness=0.5, lightmodel= light3, style=patchnogrid, orientation= [80, 30, -36]); plot3d(0, 0..1, 0..1, color=grey, glossiness=0.5, lightmodel= light3, style=patchnogrid, orientation= [80, 30, -36]);```

## A guess....

@shkarah I find it a bad idea to make an assigment to "f(x)" and then use "f[i](x)" at the same time. I am betting this would be a problem for some procedures. I do not know the actual source of the problem you've had.

## Corrected code:...

@shkarah use this:

```i := 'i': N := 4; F := sum(p^i*f[i](x), i = 0 .. N); HPMEq := (1 - p)*(diff(F, `\$`(x, 3))) + p*((diff(F, `\$`(x, 3))) + 1/2*(diff(F, x, x))*F); for i from 0 to N do equ[2][i] := coeff(HPMEq, p, i) = 0 end do;```

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