Using a compiled function inside NIntegrate gives "CompiledFunction::cfsa" message

Question

The following function is defined for Real input:

FFc = Compile[{{x, _Real}, {EF, _Real}},If[x > EF, 0., If[x == EF, 0.5, 1.]]]

FFc is now used in the function called foo:

EBoundary = 6.5;
foo[Ef_?NumericQ] := NIntegrate[FFc[x, Ef] , {x, -EBoundary, EBoundary}]

When I call foo like

foo[3.2]

I get an error message:

CompiledFunction::cfsa: "Argument x at position 1 should be a machine-size real number.

Since I'm using real numbers I have no idea why I get this message. What is the problem? Is it because If[] can return 0?

score 20 · Accepted Answer · answered Jan 18 '13 at 08:31

20

It's because FFc is being passed x and Ef symbolically, at first. To cure the problem, add an intermediate function between FFc and NIntegrate, such as

f[x_?NumericQ, Ef_?NumericQ] := FFc[x,Ef]

then

foo[Ef_?NumericQ] := NIntegrate[f[x, Ef] , {x, -EBoundary, EBoundary}]

answered Jan 18 '13 at 08:31

rcollyer

33,976
7
92
191

4

Do you perhaps know why adding "RuntimeOptions" -> {"EvaluateSymbolically" -> False} to FFc does not cure the problem? – Ajasja Jan 18 '13 at 09:40
2

@Ajasja Seems related to why FFc[-x,0.] gives error while FFc[x,0.] doesn't. I wonder why NIntegrate passes -x as argument to the function. (This comment is assuming {"EvaluateSymbolically" -> False}) – ssch Jan 18 '13 at 12:20
@Ajasja Seems if the integration region is {x,-a,a} it doesn't work, while it is unsymmetric like {x,-a-0.00001,a} it does – ssch Jan 18 '13 at 12:26
@Ajasja no idea. Compile is not my strong suit. – rcollyer Jan 18 '13 at 13:14
Thanks. Perhaps @OleksandR will see this:) – Ajasja Jan 18 '13 at 13:47
A same trick has been applied in this question, too. http://mathematica.stackexchange.com/q/40755/5943 – saturasl Mar 09 '14 at 21:41
I am worried that this solution might affect the performance boost that Compile is supposed to give. I am referring to the _?NumericQ pattern matching. Isn't there a more direct solution? Perhaps in Math 10? – a06e Oct 21 '14 at 15:42
@becko have you tried it with and without NumericQ? That is the only way to tell definitively. But, I suspect the speed hit will be marginal. – rcollyer Oct 21 '14 at 15:47
What effect does the introduction of an interim function have on performance? Is there another solution? – Doug Kimzey Apr 29 '16 at 18:31
@DougKimzey honestly, I don't know if it has much effect on performance, but relative to NIntegrate, I don't expect it to be very large. That said, you can turn off symbolic processing in NIntegrate by setting Method -> {Automatic, "SymbolicProcessing" -> 0}. – rcollyer Apr 29 '16 at 18:48

score 11 · Answer 2 · edited Apr 13 '17 at 12:55

This answer addresses Ajasja's question in rcollyer's answer:

Do you perhaps know why adding "RuntimeOptions" -> {"EvaluateSymbolically" -> False} to FFc does not cure the problem?

This is due to the fact that the methods inside NIntegrate[] (attempt to) perform a preliminary symbolic analysis, which can be helpful for integrands composed of built-in mathematical functions, but not terribly useful for compiled functions. Thus, one has to turn it off in this case, in addition to enabling the compilation options mentioned by Ajasja.

Here is a quick demonstration:

FFc = Compile[{{x, _Real}, {EF, _Real}}, 
              If[x > EF, 0., If[x == EF, 0.5, 1.]], 
              "RuntimeOptions" -> {"EvaluateSymbolically" -> False}];

With the default setting, we get this (Mathematica 10.4):

NIntegrate[FFc[x, 3.2], {x, -6.5, 6.5}]

CompiledFunction::cfsa: Argument -x at position 1 should be a machine-size real number.
CompiledFunction::cfsa: Argument -x at position 1 should be a machine-size real number.
NIntegrate::slwcon: Numerical integration converging too slowly; suspect one of the
following: singularity, value of the integration is 0, highly oscillatory integrand, or
WorkingPrecision too small.
NIntegrate::ncvb: NIntegrate failed to converge to prescribed accuracy after 9
recursive bisections in x near {x} = {3.22441}. NIntegrate obtained 9.699759342263453`
and 0.0005405922634428764` for the integral and error estimates.

before 9.69976 is returned. In contrast, if we disable symbolic processing like so:

NIntegrate[FFc[x, 3.2], {x, -6.5, 6.5}, Method -> {Automatic, "SymbolicProcessing" -> 0}]

NIntegrate::slwcon: Numerical integration converging too slowly; suspect one of the
following: singularity, value of the integration is 0, highly oscillatory integrand, or
WorkingPrecision too small.
NIntegrate::ncvb: NIntegrate failed to converge to prescribed accuracy after 9
recursive bisections in x near {x} = {3.22441}. NIntegrate obtained 9.699759342263453`
and 0.0005405922634428764` for the integral and error estimates.

we no longer get the CompiledFunction::cfsa message.

@rcollyer, I think this was asked during one of my hiatuses, so I had missed it until Jason linked to it in another question. :) — J. M.'s missing motivation, Mar 30 '16 at 13:10
Using f1p11 = Compile[{{p, _Real, 1}, {pq, _Real, 1}, {pqq, _Real, 1}}, E^-(#.# &[p + pq/2 - pqq/2]), CompilationTarget -> "C", RuntimeOptions -> {"Speed", "EvaluateSymbolically" -> False}] and NIntegrate[ f1p11[{px, py}, {1, 1}, {2, 2}], {px, py} \[Element] BoundaryDiscretizeRegion[Disk[{1, 1}/2 - {2, 2}/2, 3]], Method -> {"MonteCarlo", "SymbolicProcessing" -> 0, Method -> {"MonteCarloRule", "Points" -> 500}}, PrecisionGoal -> 3]
I get CompiledFunction::cfta: Argument {px,py}... — user40532, Oct 05 '17 at 05:44
@luu, I don't have a C compiler to verify your observations; 2. IIRC special handling is done for geometric integrals (i.e. those involving regions). This answer is mostly intended to explain the univariate case. Consider asking a new question if this is still troubling you. — J. M.'s missing motivation, Oct 13 '17 at 04:44
Sometimes life can be so easy, thank you for this comment. I also stumbled over this tiny little problem. — NeverMind, Dec 13 '18 at 17:30

Using a compiled function inside NIntegrate gives "CompiledFunction::cfsa" message

2 Answers2

Linked

Related