# Getting messages Rest::norest and Divide::indet from ContourPlot3D

Note: The bug described in this post is found in Mathematica version 9 and seems to have been fixed in version 10.

Ok I don't know if it's a bug or what, but here's what I found:

If I use this function:

ContourPlot3D[Cos[2*Pi*z] + Cos[2*Pi*y] + Cos[2*Pi*x], {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]


I get this error:

Rest::norest: Cannot take the rest of expression {} with length zero. >>

I have found that this issue is sometimes due to a need to use a numeric function. So I used:

ContourPlot3D[N[Cos[2*Pi*z] + Cos[2*Pi*y] + Cos[2*Pi*x]], {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]


And I get this error:

Divide::indet: Indeterminate expression 0./0. encountered. >> Range::range: Range specification in Range[3.,3.,0.] does not have appropriate bounds. >>

I also tried:

ContourPlot3D[Cos[2*Pi*z?NumericQ] + Cos[2*Pi*y?NumericQ] + Cos[2*Pi*x?NumericQ],
{x, 0, 1}, {y, 0, 1}, {z, 0, 1}]


But I get:

ContourPlot3D::valuef: N[Cos[2 π z?NumericQ]+Cos[2 π y?NumericQ]+Cos[2 π x?NumericQ]] must be a numerical function. >>

However, if I try any of this:

ContourPlot3D[N[Cos[z] + Cos[y] + Cos[x]], {x, 0, 2*Pi}, {y, 0, 2*Pi}, {z, 0,2*Pi}]
ContourPlot3D[Cos[z] + Cos[y] + Cos[x], {x, 0, 2*Pi}, {y, 0, 2*Pi}, {z, 0, 2*Pi}]


I get no error what-so-ever. But the error with NumericQ persists. I'd also like to point out that the NumericQ error is the only one preventing me from getting the 3D graphics.

Does anybody know what's going on?

• I Just added == 0 and no such error now. ContourPlot3D[Cos[2*Pi*z] + Cos[2*Pi*y] + Cos[2*Pi*x] == 0, {x, 0, 1}, {y, 0, 1}, {z, 0, 1}] gives !Mathematica graphics Apr 13, 2014 at 21:41
• Is it really important what is going on? Apr 13, 2014 at 21:41
• As tot the ?NumericQ issue: You should not normally use a pattern test in a function call. You are confusing this with restrictions you put on function parameters in a function definition. Apr 13, 2014 at 21:54

## What is going on?

By Trace-ing the ContourPlot3D, I found the warning (on my MMA) comes from a function SystemProtoPlotDumpfindextreme (Hereafter, the context SystemProtoPlotDump will be omitted for readability):

findextreme[{f_,
{x_, xmin_, xmax_},
{y_, ymin_, ymax_},
{z_, zmin_, zmax_}
}] := Quiet[
Check[Through[{Min, Max}[Re[Table[f,
{x, xmin, xmax},
{y, ymin, ymax},
{z, zmin, zmax}
]]]], None]]

findextreme[_] := None


This findextreme seems to be designed for finding the minimal and maximal value of the inputted function Cos[2 π z] + Cos[2 π y] + Cos[2 π x] over the plotting volume. But for OP's function, we have:

Table[Cos[2 π z] + Cos[2 π y] + Cos[2 π x], {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]


{{{3, 3}, {3, 3}}, {{3, 3}, {3, 3}}}

Thus findextreme evaluated to {3, 3}.

Now, by checking the Stack[__] when the warning message arises, we can see there is a piece of code in the definition of a local variable defaultlabels$: ChartingSimplePadding[ N[Rest[Most[ Range[Sequence @@ extreme, Subtract @@ Reverse[extreme]/(3 + 1)] ]]]]  where extreme is the result returned by findextreme. So the Range[...] part in the above code evaluated to Range[3, 3, 0]  , or when N is applied on the inputted function: Range[3., 3., 0.]  The former case goes to Rest[{}] and rises the Rest::norest warning, and the latter one itself rises the Divide::indet warning. ## Temporary solution By re-defining the findextreme function (i.e. using a random step size), I am able to avoid the problem described in OP: Clear[SystemProtoPlotDumpfindextreme] SystemProtoPlotDumpfindextreme[{SystemProtoPlotDumpf_, {SystemProtoPlotDumpx_, SystemProtoPlotDumpxmin_, SystemProtoPlotDumpxmax_}, {SystemProtoPlotDumpy_, SystemProtoPlotDumpymin_, SystemProtoPlotDumpymax_}, {SystemProtoPlotDumpz_, SystemProtoPlotDumpzmin_, SystemProtoPlotDumpzmax_} }] := Quiet[Check[Through[{Min, Max}[Re[Table[ SystemProtoPlotDumpf, {SystemProtoPlotDumpx, SystemProtoPlotDumpxmin, SystemProtoPlotDumpxmax, (SystemProtoPlotDumpxmax - SystemProtoPlotDumpxmin)/RandomReal[{2, 3}] }, {SystemProtoPlotDumpy, SystemProtoPlotDumpymin, SystemProtoPlotDumpymax, (SystemProtoPlotDumpymax - SystemProtoPlotDumpymin)/RandomReal[{2, 3}] }, {SystemProtoPlotDumpz, SystemProtoPlotDumpzmin, SystemProtoPlotDumpzmax, (SystemProtoPlotDumpzmax - SystemProtoPlotDumpzmin)/RandomReal[{2, 3}] } ]]]], None]] SystemProtoPlotDumpfindextreme[_] := None  ## Warning The defaultlabels$ is used in code:

legendfront$= LegendingPlotLegendParser["Generic"][ContourPlot3D, legendData$,
plotlegends$]; Legended[plot$, legendfront\$]


which suggests it might relate to automatic legend for ContourPlot3D, thus choosing the unit step size might has its reason. So re-defining findextreme may cause unpredictable consequence.

• Have anyone else tested this solution? Apr 15, 2014 at 0:16
• @LucianoRobino This is the what I want to know... Anyway does it work for you? Apr 15, 2014 at 0:17
• It work in my side for both cases. Although I was afraid to try it due to the unpredictable consequences for this minimal example it works fine. I'm not sure if I'll try it in the original file where the issue pop up Apr 15, 2014 at 0:20
• @LucianoRobino Great! :D And thanks for accepting. Apr 15, 2014 at 0:21
• @LucianoRobino I think as long as you don't use legend on the outputted graphics, it will be safe. Apr 18, 2014 at 7:18

I got a result using Mathematica 9.01 . It is possible that you have an older version or missing libraries. Install flash in your computer to see if this might have to do with the graphic diver.

• Interesting, my 9.0.1 home edition gives same warning as OP said. Apr 14, 2014 at 1:36
• @Silvia, Jose: Could be an OS-dependent issue. Jose's screenshot appears to be taken on Windows, while I do get the warnings on my Mac.
– user484
Apr 14, 2014 at 1:39
• @RahulNarain I'm on Windows 8 x64 .. Apr 14, 2014 at 1:41
• Provide here the results of SystemInformation[] It will be interesting to compared the results from Sulvia and Rahul Apr 14, 2014 at 5:06
• I've Trace-d down to the source of the problem, will compose a post after lunch -- if no other answers appear then ;) Apr 14, 2014 at 5:20