10
$\begingroup$

Bug introduced in 10.0 and fixed in 12.0.


I am seeing a difference in RegionMember[ ] testing a point inside a 3-vertex polygon and testing a point inside a more complex polygon:

poly1 = {{0, 0}, {4, 0}, {2, 2}};    
Print[RegionMember[Polygon[poly1], {0, 0}]]; 
(*=>True*)   
poly2 = {{11, 10}, {10, 11}, {9, 12}, {9, 13}, {8, 14}, {7, 15}, {7, 
    16}, {6, 17}, {6, 18}, {5, 18}, {4, 18}, {3, 19}, {2, 18}, {1, 
    19}, {-1, 19}, {-2, 19}, {-3, 19}, {-4, 19}, {-5, 18}, {-4, 
    18}, {-3, 16}, {-3, 16}, {-2, 14}, {-1, 14}, {-1, 12}, {0, 
    12}, {0, 10}, {1, 10}, {2, 10}, {3, 10}, {4, 10}, {5, 9}, {7, 
    10}, {7, 9}, {9, 9}, {10, 9}}; 
Print[RegionMember[Polygon[poly2], {0, 0}]]; 
(*=>Long Expression*)


         
How can I force RegionMember[ ] to evaluate to True or False?

(I'm using Version 11.3.0.0 under MacOS X.)

$\endgroup$
10
$\begingroup$

I think it's worth reporting this to support. As a workaround you can numericize the polygon:

RegionMember[
    Polygon[
        N@{
            {11,10},{10,11},{9,12},{9,13},{8,14},{7,15},{7,16},
            {6,17},{6,18},{5,18},{4,18},{3,19},{2,18},{1,19},
            {-1,19},{-2,19},{-3,19},{-4,19},{-5,18},{-4,18},
            {-3,16},{-3,16},{-2,14},{-1,14},{-1,12},{0,12},
            {0,10},{1,10},{2,10},{3,10},{4,10},{5,9},{7,10},
            {7,9},{9,9},{10,9}
        }
    ],
    {0,0}
]

False

| improve this answer | |
$\endgroup$
10
$\begingroup$

This seems like a bug. It might even be a bug I have reported in the past.

In particular, your polygon is slightly degenerate: it has {-3, 16} twice in a row, creating a zero-length edge. (This doesn't seem to be a sufficient condition alone to make RegionMember fail.)

You can remove such edges by the following replacement rule:

RegionMember[
 Polygon[poly2 //. {{a___, p : {x_, y_}, {x_, y_}, b___} :> {a, p, b},
                    {p : {x_, y_}, a___, {x_, y_}} :> {a, p}}], {0, 0}]

False

This rule doesn't work for complicated coordinate values which have the same value but a different form (testing equality is untrivial), but it's fine with integers and rationals.

Unfortunately this is not the only kind of degeneracy which can make RegionMember fail. Another sort can be seen on polygons where consecutive edges overlap on the same line (this problem persists in v12.0):

RegionMember[Polygon[{{0, 0}, {2, 0}, {1, 0}, {0, 1}}], {0, 0}]

RegionMember[Polygon[{{0, 0}, {2, 0}, {1, 0}, {0, 1}}], {0, 0}]

Numericizing the coordinates does help even in this case, though.

| improve this answer | |
$\endgroup$
4
$\begingroup$

In version 10.1 it seems I need to remove duplicates and make sure the array is unpacked:

RegionMember[Polygon @ Developer`FromPackedArray @ DeleteDuplicates @ poly2, {0, 0}]
False
| improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ Just noting, DeleteDuplicates would actually change the shape of the polygon if duplicates are not consecutive. $\endgroup$ – kirma Aug 9 '18 at 5:36
  • 1
    $\begingroup$ @kirma Good point! I guess I was only interested in making the example "work" without thought to preserving the actual intent. It also induced packing which is how I discovered that too was a problem. $\endgroup$ – Mr.Wizard Aug 9 '18 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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