1

Context

I am interested in integrating a 2D function over lines defined implicitely

Attempt

Let me just start by integrating the identify on such sets of lines which a defined using ImplicitRegion

cond1 = ImplicitRegion[
  And @@ {Sin[ Pi x y] == 0, -2 < x <= 2, -2 <= y <= 2}, {x, y}]
dcond1 = DiscretizeRegion[cond1]
NIntegrate[1, {x, y} ∈ dcond1]

Mathematica graphics

(* 24.9439 *)

Now clearly the implicit region is missing a small branch. We can check this using a different setup involving DiscretizeGraphics:

tt = ContourPlot[Sin[Pi x y ] == 0, {x, -2, 2}, {y, -2, 2},
   Frame -> False, ContourShading -> False] // DiscretizeGraphics

Mathematica graphics

ArcLength[tt]

(* 25.6601 *)

QUESTION

Is this a bug? Would you know of a workaround (given that in the end I do not want to integrate the identity but a known function over these lines)?

UPDATE

It is a bug which has disappeared in 10.0.2

chris
  • 22,860
  • 5
  • 60
  • 149
  • 1
    See closely related problem Finding length of intersection of two surfaces. See the edits of the most upvoted answer, it involved initially a bug, then I haven't checked it but it seems to be correct. Nevertheless it is in general a wrong idea to use approximate methods when symbolic approach is available (e.g. my answer to that question). – Artes Feb 05 '15 at 10:42
  • @Artes thanks for the comment. Would you agree that it is a bug though? (my real problem does not involve symbolic expressions) – chris Feb 05 '15 at 10:52
  • Of course there must be a bug in those new capabilities of Mathematica 10, nonetheless you can exploit another solutions to that question yielding correct results. – Artes Feb 05 '15 at 10:57
  • What version of Mathematica are you using on what platform? With 64-bit 10.0.2 on OS X I don't see the problem. Before trying this out I was going to say that I would be cautious about calling this a bug. While the result is clearly wrong, it's likely wrong due to the fact that all numerical methods used for these sorts of calculations rely on heuristics: they are not guaranteed to give perfect results. ContourPlot will miss pieces of curves very often, and when it doesn't miss them, if often cuts/smoothers sharp corners. This is expected. – Szabolcs Feb 05 '15 at 17:47
  • At the same time usually there are options that can be changed to get a more precise discretization. I was going to try to find out how to do this, but then surprisingly I didn't see the problem on my machine. I'm curious if this is due to a version difference (many problems fixed in 10.0.2) or due to slightly different numerical errors on different platforms/CPUs. Also, while I wouldn't call it a bug, it might still be worth reporting to give the developers a chance to improve the reliability of the discretization algorithms. – Szabolcs Feb 05 '15 at 17:49
  • I use 64-bit 10.0.1 on OS X – chris Feb 05 '15 at 18:00
  • @chris Why don't you upgrade to 10.0.2 then? – Szabolcs Feb 06 '15 at 15:58
  • I did and it worked :-) – chris Feb 06 '15 at 16:33

1 Answers1

1

It turns out that in fact DiscretizeGraphics returns directly a region object, so I can do

tt = ContourPlot[Sin[Pi x y ] == 0, {x, -2, 2}, {y, -2, 2},
Frame -> False, ContourShading -> False] // DiscretizeGraphics

then

NIntegrate[1, {x, y} ∈ tt]

(* 25.6601 *)

or more generally,

NIntegrate[x^2 y, {x, y} ∈ tt]

Pretty nifty!

So one could define a function

NImplicitRegion[cond, rg__] :=
 Module[{tt},
  tt = ContourPlot[cond, rg, Frame -> False, 
    ContourShading -> False];
  DiscretizeGraphics[tt]]

so that e.g.

NImplicitRegion[Cos[x y] == 0, {x, -2, 2}, {y, -2, 2}]

returns

Mathematica graphics

chris
  • 22,860
  • 5
  • 60
  • 149