This is undoubtedly rather elementary, but the remedy escapes me presently (and does not, as far as I can see, readily appear in Help).

I'm engaged in an iterative process with several computations at each iteration, and for rare steps I generate:

Power::infy: Infinite expression 1/Sqrt[0] encountered


CompiledFunction::cfse: Compiled expression ComplexInfinity should be a "machine-size real number


CompiledFunction::cfex: Could not complete external evaluation; proceeding with uncompiled evaluation

I would just simply like to bypass such steps (while recording--though not essential--their specific numbers).

How might I proceed?


closed as off-topic by Michael E2, LCarvalho, m_goldberg, MarcoB, Öskå Sep 8 at 17:17

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question cannot be answered without additional information. Questions on problems in code must describe the specific problem and include valid code to reproduce it. Any data used for programming examples should be embedded in the question or code to generate the (fake) data must be included." – Michael E2, LCarvalho, m_goldberg, MarcoB, Öskå
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    $\begingroup$ How and why do you get CompiledFunction errors? Why do you compile uncompilable code (indicated by CompiledFunction::cfex)? $\endgroup$ – Michael E2 Sep 4 at 22:47

The following example fits the description in the OP; however, the description is so vague, I have my doubts about the helpfulness of the example:

cf = Compile[{x}, 1/y /. y -> (x - 2), 
   RuntimeOptions -> {"RuntimeErrorHandler" -> Function[Throw[$Failed[#]]]}];
Table[Catch@cf[xx], {xx, 3}]

Mathematica graphics

The default "RuntimeErrorHandler" is to evaluate the uncompiled expression; changing the "RuntimeErrorHandler" does not change the text of the error message.

  • $\begingroup$ I guess OP is some acronym for the question posed. This is all very sophisticated, and somewhat beyond my full understanding. I guess my question was how does one straightforwardly move on to the next iteration if such problems or any other errors arise. In other words, "let's just forget about this step, we have enough results without it". $\endgroup$ – Paul B. Slater Sep 5 at 3:09
  • $\begingroup$ @PaulB.Slater (1) Yes, "OP" = "Original Post" (or in other contexts, "Original Poster", i.e. the author). (2) To skip the step, try changing Throw[$Failed[#]] to Throw[Nothing]. $\endgroup$ – Michael E2 Sep 5 at 3:31
  • $\begingroup$ In general Catch[...; Throw[value];...] is a standard way to return a value from deep within code (for instance, from inside a loop, inside a subroutine such as inside the compiled environment WVM in this case). It is commonly used to stop a computation when an exceptional situation occurs, which is exactly your use-case here. $\endgroup$ – Michael E2 Sep 5 at 11:59
  • $\begingroup$ Thanks! So, how can I skip the subsequent computations--which would contaminate my cumulative results--in the error-producing step and move onto the next iteration (bump the loop parameter up by 1)? $\endgroup$ – Paul B. Slater Sep 5 at 16:39
  • $\begingroup$ Per the first comment of Michael E2 above, what might one do rather than "skipping the step" in question, instead directly Goto another statement, several statements removed from the error-producing one? That is skip those intervening statements that would try to process the erroneous results (leading to Indeterminate outcomes). $\endgroup$ – Paul B. Slater Sep 6 at 2:31

Well, I tracked down ("divide-and-conquer") the specific iteration (16,630,333) at which the error messages occurred--and found that a certain number, generated through a process involving random numbers, was testing as equal to 0. The log of this number then yielded the ComplexInfinity in question. So, now I'm checking at each subsequent iteration for this phenomenon. Hopefully, this will fully solve the specific problem at hand (but perhaps not the more general problem posed--of simply omitting/skipping iterations at which [arbitrary] errors occur, without necessarily pinpointing their nature).

In the continuing series of iteration, things ran smoothly until iteration 46,894,463 (which I had to track down between 46 and 48 million) when the same error messages were generated. However, my testing for 0 to bypass the step did not now succeed. The function I was compiling at this iteration had the value {0., 0., 0., Indeterminate, 0., 0., Indeterminate, 0., Indeterminate, Indeterminate}. So, I went back and further incorporated a test for the entries of the vector being 0. But, this to my surprise and puzzlement did not succeed in bypassing the step. So, at this point, I'm simply explicitly bypassing iteration 46,894,463.

Undoubtedly, as MichaelE is suggesting, some use of the Throw and Catch commands should be able to address my problem in general. But I don't sufficiently appreciate their use at this point--but will try to do so. Until that point, I may have to simply follow an ad hoc procedure--that is tracking down the "rogue" iteration and going back and explicitly excluding it.


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