# Mathematica Computational Limitations and ColorFunctions?

Observe the following function I have defined in Wolfram Mathematica and the array plot below:

nd[y_, a_, b_,
n_] := (Binomial[b - a + 1, y]*
Sum[((-1)^i)*Binomial[y, i]*((y - i)/(b - a + 1))^n, {i, 0, y}]);
ArrayPlot[Table[nd[1, 1, K, n], {K, 1, 400}, {n, 1, 400}],
ColorFunction -> "BlueGreenYellow", DataReversed -> True, ColorFunctionScaling->False,
FrameStyle -> Directive[Thin, Black], FrameTicks -> Automatic]


The output is this:

Wait... what on Earth? That hideous red color certainly isn't part of the "BlueGreenYellow" ColorFunction! Where could it possibly be coming from?

Upon closer inspection, I'm still not entirely sure what's going wrong here. Perhaps I have hit a computational limitation of Mathematica? The color should obviously be dark blue where that red pops up because my function evaluates to a very small number. But perhaps Mathematica is giving up on the evaluation altogether and just replaces the parts where it gave up with that color. I'm honestly not sure. Either way, that hideous red color is consistent regardless of the color scheme that I use. For example, with DarkRainbow:

It's the exact same shade of red. Ideally, I would be able to control this color in some fashion; preferably I could change it to a dark blue. But most importantly, what exactly is going on here? Is it possible to change this dark red color?

• It seems to be fixed if you write N@Table[...], i.e. apply N to your data. Currently, you're passing an exact expression for a very, very small number to the color function. I don't think there is any good reason for why this shouldn't work, but it may be related to the problem somehow. (To see this expression, evaluate Min@Table[nd[1, 1, K, n], {K, 1, 400}, {n, 1, 400}].) Further evidence that it is related to the problem: If you try to pass that value to ColorData["BlueGreenYellow", min value here], then it won't recognize it as a number and won't return a color. Commented Nov 25, 2017 at 23:24

I believe the "hideous" red color is an indication that something is going terribly wrong with your plot. Compare:

ColorData["BlueGreenYellow"][nd[1, 1, 100, 200]]
ColorData["BlueGreenYellow"][nd[1, 1, 100, 100]]


Blend["BlueGreenYellow", 1/100000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000]

RGBColor[0.122103, 0.00901808, 0.39826]

For the first color, the argument is too small, and ColorData doesn't return a valid color. When Mathematica creates a raster using the given ColorFunction, it has to replace the invalid color above with something, and the default in Mathematica is to use red when something has gone wrong. To fix this, just use N:

ArrayPlot[
N @ Table[nd[1, 1, K, n], {K, 1, 400}, {n, 1, 400}],
ColorFunction->"BlueGreenYellow",
DataReversed->True,
ColorFunctionScaling->False,
FrameStyle->Directive[Thin,Black],
FrameTicks->Automatic
]


Not surprisingly, only a very narrow strip along the bottom and the left have values sufficiently different from 0 to appear yellow.

• Yes, that thin yellow strip was perfectly intended behavior. I just didn't realize that the "N@" was necessary to solve the issue. Thank you very much for the insight! Commented Nov 25, 2017 at 23:53
• It's curious, though, how it can be "too small" when 0 is an accepted input. I lean towards calling this a bug, especially since the fix is just to apply N, which could be easily done internally by ColorData. Commented Nov 27, 2017 at 14:58