Bug in densityplot in Maple V.5 (13.8.99)

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

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

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:

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

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: