number of digits outputted from getBBox is sometimes not compatible as input to isPointInside

[rgedge]

function isItABug() {
    var s = Snap(1000, 1000);
    var p = s.path("M 720,783 L 840,783 L 840,903 L 720,903 z");
    p.attr("fill", "yellow");

    // var t = s.text(780,843,"101");
    // change some attributes, do a transform, etc. 
    // use t.getBBox() to get a bounding box
    // one corner of the bounding box returned is
    var cx = 791.984375;
    var cy = 834.125;

    //drop a circle on the point to visualize
    var c = s.circle(cx,cy,10);
    c.attr("fill", "black");

    console.log("Is " + cx + "," + cy + " within the square?" + Snap.path.isPointInside(p, cx,cy));     
    //result:
    //          Is 791.984375,834.125 within the square?false

    var x = Math.round(cx);
    var y = Math.round(cy);
    console.log("is " + x + "," + y + " within the square?" + Snap.path.isPointInside(p, x, y));
    // result:
    //      is 792,834 within the square?true
}

[ThomasBrierley]

isPointInside has a number of bugs i'm currently working through which cause false positives and false negatives.

However... even if it was working perfectly, you can't expect finite precision intersection tests to do what you expect on boundaries. If it's on the corner of the box it should be ok to call it either a true or false intersection.

Why do you need to test intersection on boundaries?