Christian Wolinski

MaplePrimes Activity


These are replies submitted by Christian Wolinski

@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:

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

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

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

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

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

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

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

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

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

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

 

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

@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