Bug introduced in 11.0 and fixed in 11.1

Reported as CASE:3686963, 12 Aug 2016

I attempted to determine whether the problem with RandomPoint identified in my answer to question 89384 had been fixed in

(* 11.0.0 for Microsoft Windows (64-bit) (July 28, 2016) *)

In fact, a worse problem seems to have arisen. I began by attempting to reproduce the first plot in the question by

s = 0.36109;
t = 1*(1 - s);
equation1 = 1.505 < (1 - s)*8*(Sin[2*x]*Sin[z]*Cos[y] + Sin[2*y]*Sin[x]*Cos[z] +
    Sin[2*z]*Sin[y]*Cos[x]) - s*4*(Cos[2*x]*Cos[2*y] + Cos[2*y]*Cos[2*z] + 
    Cos[2*z]*Cos[2*x]) - t;
region1 = ImplicitRegion[equation1 && 6 <= x - y + 2*z <= 7, {{x, -5*Pi, 5*Pi}, 
    {y, -5*Pi, 5*Pi}, {z, -10, 10}}];
RandomPoint[region1, 10^4];

However, RandomPoint ran for about 30 minutes, consuming as much as 12 GB of memory, before the kernel crashed. This behavior is reproducible on my computer.

In contrast,

(* 10.4.1 for Microsoft Windows (64-bit) (April 11, 2016) *)

produces the result in the earlier question in a few seconds, as did version 10.2.0.

My questions are,

  • Can others reproduce this behavior?
  • Is it a bug?


As István Zachar points out in a comment below, region1 can be displayed with RegionPlot3D, which takes a few minutes.

RegionPlot3D[region1, PlotPoints -> 200, BoxRatios -> {1, 1, 1}]

enter image description here

Although region1 is complicated, it does occupy a reasonable fraction of the plane on which it lies. Further, the plane itself can be represented in a few seconds by RandomPoint

region2 = ImplicitRegion[6 < x - y + 2*z < 7, 
    {{x, -5*Pi, 5*Pi}, {y, -5*Pi, 5*Pi}, {z, -10, 10}}];
pts2 = RandomPoint[region2, 10^4];
plt2 = ListPointPlot3D[pts2, Axes -> True, AxesLabel -> {"x", "y", "z"}, 
    BoxRatios -> {1, 1, 1}, 
    PlotRange -> {{x, -5*Pi, 5*Pi}, {y, -5*Pi, 5*Pi}, {z, -10, 10}}]

enter image description here

Yet, RandomPoint cannot find even a single point in region1.

pts1 = RandomPoint[region1]

Instead, it also fails in about 30 minutes after using over 12 GB of memory.

  • 4
    $\begingroup$ I can reproduce the behaviour in 11.0 while in 10.4 it's perfectly fine. I suspect this is a bug. $\endgroup$
    – Wjx
    Commented Aug 12, 2016 at 2:49
  • $\begingroup$ I'm seeing this too, perhaps report it. It seems quite severe... $\endgroup$
    – ktm
    Commented Aug 12, 2016 at 4:27
  • $\begingroup$ Are you sure that your region is not one with lots of disconnected almost-nulldimensional subregions on which RandomPoint ultimately runs out of memory and crashes? Because RegionMeasure[region1] fails on it too, and RegionPlot3D[region1, PlotPoints -> 50, MaxRecursion -> 1] shows something like this. It would be easier to debug the issue if you were to simplify your region to 2D, as the 3D plot indicates that the region is actually along a plane. $\endgroup$ Commented Aug 12, 2016 at 9:08
  • $\begingroup$ @IstvánZachar Thank you for your observations, which prompted my addition to the question above. $\endgroup$
    – bbgodfrey
    Commented Aug 12, 2016 at 14:12
  • $\begingroup$ It is RegionDimension[region1] that is having trouble, in 10.4 it would give up quickly. $\endgroup$
    – ilian
    Commented Aug 12, 2016 at 21:08

1 Answer 1


As part of its algorithm, RandomPoint attempts to determine the region dimension by calling


In version 10.4, the above gives up quickly without returning a result, and RandomPoint proceeds by using a heuristic estimate. But in version 11.0, RegionDimension tries harder to compute the dimension, which is a rather costly symbolic computation going through heavy machinery like Reduce. It may be very slow and there is no guarantee of success, particularly in the case of a transcendental system.

Thank you for bringing up this example, the developers are aware of the issue and will look into possible improvements (for example, TimeConstrained could have been used to keep the runaway computation at bay).

  • $\begingroup$ Do you think this is a bug? If yes, can you tag accordingly please? $\endgroup$
    – Szabolcs
    Commented Aug 18, 2016 at 11:59
  • $\begingroup$ Could you take a look at this (different) post and see if any of those behaviours may be bugs? It's all too vague to write to support but it looks like it's worth pointing it out. $\endgroup$
    – Szabolcs
    Commented Aug 19, 2016 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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