Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

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?

share|improve this question
1  
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 –  Nasser Apr 13 at 21:41
1  
Is it really important what is going on? –  Artes Apr 13 at 21:41
1  
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. –  Sjoerd C. de Vries Apr 13 at 21:54

2 Answers 2

up vote 2 down vote accepted

What is going on?

By Trace-ing the ContourPlot3D, I found the warning (on my MMA) comes from a function System`ProtoPlotDump`findextreme (Hereafter, the context System`ProtoPlotDump` 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$:

Charting`SimplePadding[
    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[System`ProtoPlotDump`findextreme]

System`ProtoPlotDump`findextreme[{System`ProtoPlotDump`f_,
            {System`ProtoPlotDump`x_,
                System`ProtoPlotDump`xmin_, System`ProtoPlotDump`xmax_},
            {System`ProtoPlotDump`y_,
                System`ProtoPlotDump`ymin_, System`ProtoPlotDump`ymax_},
            {System`ProtoPlotDump`z_,
                System`ProtoPlotDump`zmin_, System`ProtoPlotDump`zmax_}
            }] := Quiet[Check[Through[{Min, Max}[Re[Table[
                            System`ProtoPlotDump`f,
                            {System`ProtoPlotDump`x,
                                System`ProtoPlotDump`xmin, System`ProtoPlotDump`xmax,
                                (System`ProtoPlotDump`xmax - System`ProtoPlotDump`xmin)/RandomReal[{2, 3}]
                            },
                            {System`ProtoPlotDump`y,
                                System`ProtoPlotDump`ymin, System`ProtoPlotDump`ymax,
                                (System`ProtoPlotDump`ymax - System`ProtoPlotDump`ymin)/RandomReal[{2, 3}]
                            },
                            {System`ProtoPlotDump`z,
                                System`ProtoPlotDump`zmin, System`ProtoPlotDump`zmax,
                                (System`ProtoPlotDump`zmax - System`ProtoPlotDump`zmin)/RandomReal[{2, 3}]
                            }
                            ]]]], None]]

System`ProtoPlotDump`findextreme[_] := None

Warning

The defaultlabels$ is used in code:

legendfront$ = 
            Legending`PlotLegendParser["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.

share|improve this answer
    
Have anyone else tested this solution? –  Luciano Robino Apr 15 at 0:16
    
@LucianoRobino This is the what I want to know... Anyway does it work for you? –  Silvia Apr 15 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 –  Luciano Robino Apr 15 at 0:20
    
@LucianoRobino Great! :D And thanks for accepting. –  Silvia Apr 15 at 0:21
    
@LucianoRobino I think as long as you don't use legend on the outputted graphics, it will be safe. –  Silvia Apr 18 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.

enter image description here

share|improve this answer
    
Interesting, my 9.0.1 home edition gives same warning as OP said. –  Silvia Apr 14 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. –  Rahul Apr 14 at 1:39
    
@RahulNarain I'm on Windows 8 x64 .. –  Silvia Apr 14 at 1:41
    
Provide here the results of SystemInformation[] It will be interesting to compared the results from Sulvia and Rahul –  Jose E Calderon Apr 14 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 ;) –  Silvia Apr 14 at 5:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.