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 Developer`PackedArrayQ@Developer`ToPackedArray[{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.)
Additionally:
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.
RLink, partly intentionally: can you envision any meaningful application of them on the "other side"? – Leonid Shifrin Feb 04 '13 at 21:07inf, 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 butrfun2(rfun1(data))would work in R. Admittedly, it's not a big deal. – Szabolcs Feb 04 '13 at 21:19REvaluate["Inf"]is{Infinity}and not{Inf`}, so you thought about it too, and RLink handles it correctly), and this is what prompted my question. My question was: is it safe to use the solution I described? If yes, why not use it? It's so simple. If not, then I agree that implementing a more complex solution is not worth the trouble at this stage. – Szabolcs Feb 04 '13 at 21:34Inf`etc) long time ago, and back then I decided to not use them, but I don't remember the reason alas. – Leonid Shifrin Feb 04 '13 at 21:49Developer`PackedArrayQreturns 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 05 '13 at 04:51