# Passing back “NaN” and “Inf” to C via MathLink

In the "usual" double representation of floating point numbers in C there is a NaN and an Inf value. (I'm saying usual because I am not deeply familiar with the various floating point formats that are used in practice. Please correct me when necessary.)

These special values can be sent back to Mathematica via MathLink, and they will display as Nan and Inf. NumberQ returns true on them.

Short version: How can these special values be created in Mathematica and sent back to C? (But please see the long version)

Long version:

Mathematica represents these special cases as Infinity, -Infinity, ComplexInfinity, and Indeterminate. These symbols can be sent back through MathLink, and handled on the C but, but I'd prefer not to do this because: 1. It's complicated. 2. It's slow. I'd have to use MLPutReal64* functions to make the packed array case fast anyway. So I'd prefer to somehow be able to use MLPutReal64* to send NaN and Inf as well.

How can we persuade MLPutReal64 to handle these values? We'd have to create the same thing that MLGetReal64 returns for NaNs, and send that. It seems there's no built-in way to create these in Mathematica, but I can always write a MathLink-based function that returns them and then keep them as constants in Mathematica. I tried this and I verified that it works on OS X 64 bit.

The big question is: is it safe to do this? Am I going to run into problems? Is the program going to be portable among the main platforms (Win/Lin/OSX, both 32 and 64 bit)?

To make the question completely clear, I'd like to do something like this:

numbers = {1., 100., 100000., Infinity}

inf = getInf[] (* MathLink-based function that returns "Inf " *)

sendToC[ numbers /. Infinity -> inf ]


(If anyone is interested, it seems that DeveloperPackedArrayQ@DeveloperToPackedArray[{1., 2., 3., 4., inf}] returns True. Also a big warning for those who'd think of doing calculations with these special values in Mathematica: don't!! Nearly all operations on them, even pattern matching, are broken and return nonsense results. E.g. MatchQ[Inf, NaN] === True, Inf + 1 === 1, etc.)

Here's a relevant discussion of the issue on MathGroup by John Fultz. There are two suggestions in that thread (other than sending symbols directly): 1. Designating certain Mathematica-representable floating point values to denote NaN and Inf. 2. Explicitly passing the integer indices of NaNs and Infs in the array. But if the way I described above works, I'd much rather just use that, as it's so much simpler.

-
FWIW, I did not yet implement sending such quantities to R via RLink, partly intentionally: can you envision any meaningful application of them on the "other side"? – Leonid Shifrin Feb 4 '13 at 21:07
@Leonid One (theoretical!) application is some kind of hybrid R/Mathematica code which first calls an R functions, takes the result, calls a (simple) Mathematica function on it, then calls a second R function on the output. If the first R function returned an inf, it'll break the hybrid program, even if it wouldn't break an R-only program. I.e. runf2@rfun1[data] would not work in Mathematica but rfun2(rfun1(data)) would work in R. Admittedly, it's not a big deal. – Szabolcs Feb 4 '13 at 21:19
But, the point is, we do support the transfer of these quantities from R to Mathematica. So, the recipe so far is simple: just don't send them back to R. I have a hard time coming up with something meaningful that R can do with those quantities if it receives them from Mathematica. The reverse is not necessariy true due to symbolic nature of Mathematica. – Leonid Shifrin Feb 4 '13 at 21:22
We decided to not include the reverse transfer for these quantites for the first version of RLink. If we get some feedback requesting it, we'll implement it in the future versions. – Leonid Shifrin Feb 4 '13 at 21:23
Interesting that DeveloperPackedArrayQ returns true in that case. An alternative, that may be safer is to use this guy's suggestion (same thread, just deeper). More data is required to pass, but not necessarily that much. – rcollyer Feb 5 '13 at 4:51

I decided that it is not worth risking breakage by doing this. It is possible to create values displayed as Inf and NaN in Mathematica in hackish ways (returning them through MathLink), but these don't behave very well. For example, in v9 on OS X, 1 + Inf == 1; MatchQ[NaN, -Inf] === True but NaN == -Inf is False.
As several people have suggested, I decided on passing the integer indices of where each of Indeterminate, Infinity and -Infinity are located, for both directions of transfer through MathLink. This is more work, but it's safe.