7.44 Bug in densityplot in Maple V.5 (13.8.99)

7.44.1 Robert Michael Sinclair

Densityplot (in the plots package) fails to produce correctly scaled RGB values when given a procedure in which complex numbers appear - even if they have no influence on the return value. In the following, I define two procedures, f and g, which differ only in the value of an irrelevant constant. In f it is 2001, in g it is I (i.e. sqrt(-1)). Note the difference in the output of densityplot.

This bug is annoying because it prevents one from plotting the Mandelbrot set in an obvious manner (using a procedure which iterates a complex map but returns the integer number of iterations).

    |\^/|     Maple V Release 5.1 (WMI Campus Wide License) 
._|\|   |/|_. Copyright (c) 1981-1998 by Waterloo Maple Inc. All rights 
 \  MAPLE  /  reserved. Maple and Maple V are registered trademarks of 
 <____ ____>  Waterloo Maple Inc. 
      |       Type ? for help. 
> with(plots): 
> f := proc(X,Y) 
>        local Z; 
>        if X>0 then Z := 2001*Y 
>               else Z := 0 
>        fi; 
>        X+100 
>      end: 
> g := proc(X,Y) 
>        local Z; 
>        if X>0 then Z := I*Y 
>               else Z := 0 
>        fi; 
>        X+100 
>      end: 
> densityplot(f,-1.5..1.5,-1.5..1.5); 
 
  GGGGGGGGGGGGGGGGGG1.5*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGG1*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGG0.5*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
  GGGGGGGGGGGGGGGGGGGGG*GGGGGGGGGGGGGGGGGGGGGG 
 -********************************************- 
 -1.5HHHH-1HHHH-0.5HHH0*HHHHH0.5HHHHH1HHHHH1.5 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHH-0.5*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHH-1*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHH-1.5*HHHHHHHHHHHHHHHHHHHHHH 
 
> densityplot(g,-1.5..1.5,-1.5..1.5); 
 
  HHHHHHHHHHHHHHHHHH1.5*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHH1*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHH0.5*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
 -********************************************- 
 -1.5HHHH-1HHHH-0.5HHH0*HHHHH0.5HHHHH1HHHHH1.5 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHH-0.5*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHH-1*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHHHHHH*HHHHHHHHHHHHHHHHHHHHHH 
  HHHHHHHHHHHHHHHHH-1.5*HHHHHHHHHHHHHHHHHHHHHH
 

It is corrected with Maple 6. (U. Klein)

7.44.2 Robert Israel (20.8.99)

There are actually two bugs to note here. The first is, I think, the worst because it interchanges the x and y variables (note that the shading seems to depend on y rather than \(x\)). This occurs when Maple uses evalhf (i.e. hardware floating-point) to evaluate the function to be plotted. The occurrence of I prevents evalhf from working, so Maple uses ordinary evalf (software floating-point), and here the second bug occurs: the RGB values are not properly scaled. Of course you could scale the function to be plotted yourself. But here’s a fix:

> fixgray:= proc(p) 
   local newp, cspecs, csp, cseq, cmax, cmin, i; 
   cspecs:= indets(p,specfunc(anything,COLOR)); 
   newp:= p; 
   for csp in cspecs do 
     cseq:= op(2..-1,csp); 
     cmax:= max(cseq); 
     cmin:= min(cseq); 
     cseq:= seq((cseq[i]-cmin)/(cmax-cmin),i=1..nops(csp)-1); 
     newp:= subs(csp=COLOR(op(1,csp),cseq), newp); 
     od; 
   newp; 
   end; 
 
> fixgray(densityplot(g,-1.5..1.5,-1.5..1.5));
 

This should work OK. Note that this does not fix the interchange of \(x\) and \(y\).

7.44.3 Helmut Kahovec (20.8.99)

In Release 4 both density plots are correct.

In Release 5 the density plot of f is also incorrect: there should be a horizontal density gradient instead of a vertical one. Since the body of f can be evaluated by evalhf() the procedure plots[densityplot]() calls `plot3d/density_hf`() plus `plot3d/densfunc_hf`(), `plot3d/colorsur2`() plus `plot3d/cgridhf2`(), and `plots/densityplot/RGB_hf`(), respectively.

`plot3d/density_hf`(), `plot3d/colorsur2`(), and `plots/densityplot/RGB_hf`() define certain hfarrays A, B, and C. `plot3d/densfunc_hf`(), `plot3d/cgridhf2`(), and `plots/densityplot/RGB_hf`() process A, B, and C. The processing is done by nested loops.

The inner index corresponds to \(x\) and the outer index to \(y\). However, in the procedure `plot3d/cgridhf2`() the inner index corresponds to \(y\) and the the outer index to \(x\).

This inconsistency exchanges the coordinate axes of all density plots.

Since the first line of g (i.e., Z:=I*Y;) cannot be evaluated using evalhf() the procedure plots[densityplot]() calls `plot3d/colorsur`() which in turn calls `plot3d/cgridf`(). The latter also has that inconsistency w.r.t. the loop indices. Additionally, it incorrectly computes the COLOR() part of the plot structure in this case and the density plot appears to be black.

Z:=5 mod 2; cannot be evaluated by evalhf() either. Hence the following procedure h gives an incorrect (black) density plot, too:

> restart; 
 
> h:=proc(X,Y) 
> local Z; 
>   Z:=5 mod 2; 
>   X+100 
> end: 
 
> densityplot(h,-1.5..1.5,-1.5..1.5,axes=FRAME);