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 inﬂuence on the return value. In the following, I deﬁne two procedures, f and g, which diﬀer only in the value of an irrelevant constant. In f it is 2001, in g it is I (i.e. sqrt(-1)). Note the diﬀerence 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)
There are actually two bugs to note here. The ﬁrst 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 ﬂoating-point) to evaluate the function to be plotted. The occurrence of I prevents evalhf from working, so Maple uses ordinary evalf (software ﬂoating-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 ﬁx:
This should work OK. Note that this does not ﬁx the interchange of \(x\) and \(y\).
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`() deﬁne 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 ﬁrst 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: