The "argument" of a complex number satifies:
argument( exp(y*I) ) = y
whenever -Pi < y < Pi. Of course Maple knows (most of) this.
> simplify( argument(exp(y*I)), assume=real ); arctan(sin(y), cos(y))
Thus the following two colour plots should be identical.
> interface(plotdevice=x11); #Change or comment out, as needed. > plot3d( x, x=0..1, y=0..1, color=y , axes=boxed); > plot3d( x, x=0..1, y=0..1, color=argument(exp(I*y)), axes=boxed);
*** Why are the x and y axes switched on the colour function?!! ***
The same trouble occurs using alternate plot syntax:
> plot3d( ((x,y)->x), 0..1, 0..1, color=( (x,y)->argument(exp(I*y)) ), axes=boxed);
...and propogates to other plotting functions that internally use "argument":
> plots[complexplot3d]( exp, 0-3*I..1+3*I, axes=boxed );
I do not know whether this is a bug in plot3d, argument or something deeper. The bug probably does not involve "exp", as is checked by setting "color=argument(10+I*y)"
TTY Iris, Release 5, SUN SPARC SOLARIS, Jan 11 1998
It is corrected with Maple 6. (U. Klein)
There is a bug in Release 5 which affects colours in a number of plotting commands. It seems to have to do with whether or not evalhf is used to produce the array of colours. Any mention of complex numbers prevents evalhf from being used. For some commands, the results are only correct if evalhf is used, for other commands they are only correct if evalhf is not used.
> plot3d(x, x=0..1, y=0..1, color=y); uses evalhf and comes out normally > plot3d(x, x=0..1, y=0..1, color=Re(y)); doesn't use evalhf, x and y are switched in colours
On the other hand
> plots[densityplot](x, x=0..1, y=0..1); uses evalhf, x and y are switched in colours > plots[densityplot](Re(x), x=0..1, y=0..1); does not use evalhf, x and y are switched > plots[complexplot3d]([x,y],x=0..1,y=0..1); uses evalhf, works > plots[complexplot3d](exp(z),z=-1-Pi*I .. 1+Pi*I); doesn't use evalhf, x and y are switched in colours.
In the cases where the colours are switched, you get an error message if you use the "grid" option with unequal components:
> plot3d(x, x=0..1, y=0..1, color=Re(y), grid=[2,3]); Error, (in plot3d/color) invalid subscript selector
The problem is solved if you use evalc:
>argument( exp(y*I) ) ; argument(exp(I y)) > evalc(%); y
and in the color plots:
>plot3d( x, x=0..1, y=0..1, color=evalc(argument(exp(I*y))), axes=boxed);
Let’s first reproduce your bug:
> restart; > plot3d(x,x=0..1,y=0..1,color=y,axes=boxed); > plot3d(x,x=0..1,y=0..1,color=argument(exp(I*y)),axes=boxed);
Release 4 does it right, Release 5 does it wrong. The reason for the difference is that in R4, on the debugger line 38 of the procedure `plot3d/color` the color grid is defined by
za:=array(0..m,0..n);
The bounds m,n of za correspond to the parameters m,n in the calls to procedures like `plot3d/colorsur`. Within `plot3d/cgridf` za is processed in do loops. Thus m,n are used consistently. But in R5, on the debugger line 8 of the procedure `plot3d/cgridf` the color grid is differently defined by
grid:=[seq([seq([xmin+i*xinc,ymin+j*yinc],i=1..m+1)],j=1..n+1)];
The sizes m,n of grid again correspond to parameters m,n in the calls to procedures like `plot3d/colorsur`. Those procedures still process m,n as array indexes. Thus m,n are used inconsistently.
That inconsistency may best be seen as follows. We create the 3x2 array A:
> m:=3: n:=2: > A:=array(1..m,1..n): > print(A); [A[1, 1] A[1, 2]] [ ] [A[2, 1] A[2, 2]] [ ] [A[3, 1] A[3, 2]]
If we use do loops then we construct the array A consistently:
> S:=NULL: > for i to m do > s:=NULL; > for j to n do > s:=s,A[i,j] > od; > S:=S,[s] > od: > convert([S],matrix); [A[1, 1] A[1, 2]] [ ] [A[2, 1] A[2, 2]] [ ] [A[3, 1] A[3, 2]]
But if we use seq() and list of lists then we construct a different array:
> convert([seq([seq(A[i,j],i=1..m)],j=1..n)],matrix); [A[1, 1] A[2, 1] A[3, 1]] [ ] [A[1, 2] A[2, 2] A[3, 2]]
In order to get the original array A we must exchange the range of index i with that of index j:
> convert([seq([seq(A[i,j],j=1..n)],i=1..m)],matrix); [A[1, 1] A[1, 2]] [ ] [A[2, 1] A[2, 2]] [ ] [A[3, 1] A[3, 2]]
Hence we immediately see the following bug fix for Release 5:
> `plot3d/cgridf`:=proc(f,xmin,xmax,ymin,ymax,m,n) > local i,j,xinc,yinc,x,y,fmin,fmax,scale,firstf,grid,do_f,t,u; > global _plotDigits; > option `Copyright (c) 1992 by George Labahn. All rights reserved.`; > xinc:=(xmax-xmin)/m; > yinc:=(ymax-ymin)/n; > firstf:=true; > fmin:=traperror(evalf(f(xmin,ymin))); > if fmin=lasterror then fmin:=0 fi; > fmax:=fmin; > grid:=[seq([seq([xmin+i*xinc,ymin+j*yinc],j=1..n+1)],i=1..m+1)]; > # ^^^^^^^^ ^^^^^^^^ > if _plotDigits<=evalhf(Digits) then > do_f:=proc(u) > local result; > option `Copyright (c) 1997 Waterloo Maple Inc. All rights reserved.`; > result:=traperror(evalhf(f(u[1],u[2]))); > if result=lasterror then > result:=traperror(evalf(f(u[1],u[2]))); > if not type(result,'numeric') then > result:=0 > else > fmin,fmax:=`if`(result<fmin,result,fmin), > `if`(fmax<result,result,fmax) > fi > fi; > result > end > else > do_f:=proc(u) > local result; > option `Copyright (c) 1997 Waterloo Maple Inc. All rights reserved.`; > result:=traperror(evalf(f(u[1],u[2]))); > if not type(result,'numeric') then > result:=0 > else > fmin,fmax:=`if`(result<fmin,result,fmin), > `if`(fmax<result,result,fmax) > fi; > result > end > fi; > grid:=map(t->map(do_f,t),grid); > if fmin<fmax and (1<fmax or fmin<0) then > scale:=1/(fmax-fmin); > grid:=map(u->map(t->scale*t-fmin,u),grid) > fi; > grid > end:
Now the two color plots are identical:
> plot3d(x,x=0..1,y=0..1,color=y,axes=boxed); > plot3d(x,x=0..1,y=0..1,color=argument(exp(I*y)),axes=boxed);
PS. If you copy the Maple commands of my reply into a fresh Maple session then be sure to reproduce the bug first, i. e., execute
> plot3d(x,x=0..1,y=0..1,color=argument(exp(I*y)),axes=boxed);
before you enter the new definition of `plot3d/cgridf`. Otherwise the new definition will be overwritten by the old one.