Reading NaN & Inf in mex files

[gOS]

I've got a function which reads in text files formatted in a specific way. Thanks to windows, these files can sometimes contain values like 1.#INF or 1.#IND or even 1.#QNAN. As you can see these are window's own versions of Inf and NaN. These can also be negative.

I was able to produce an NaN value which Octave recognized as NaN with:
double nan = std::numeric_limits<long double>::quiet_NaN();

However, double inf = std::numeric_limits<long double>::infinity(); was interpreted somewhere as meaning NaN as well instead of inf.

Does anyone have any suggestions as to how to correct this?

[gOS]

I forgot you guys usually like to have an example of code.

#include "mex.h"
#include <iostream>

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
        long double nan = std::numeric_limits<long double>::quiet_NaN(); // produces 1.#QNAN
        long double inf = std::numeric_limits<long double>::infinity(); // produces 1.#INF

        plhs[0] = mxCreateDoubleMatrix(1,1,mxREAL); // Works
        long double* output = mxGetPr(plhs[0]);
        output[0] = nan;

        plhs[1] = mxCreateDoubleMatrix(1,1,mxREAL); // Does not work
        long double* output2 = mxGetPr(plhs[1]);
        output2[0] = inf;
}

gOS wrote:

I've got a function which reads in text files formatted in a specific way. Thanks to windows, these files can sometimes contain values like 1.#INF or 1.#IND or even 1.#QNAN. As you can see these are window's own versions of Inf and NaN. These can also be negative.

I was able to produce an NaN value which Octave recognized as NaN with:
double nan = std::numeric_limits<long double>::quiet_NaN();

However, double inf = std::numeric_limits<long double>::infinity(); was interpreted somewhere as meaning NaN as well instead of inf.

Does anyone have any suggestions as to how to correct this?

[gOS]

gOS wrote:

I've got a function which reads in text files formatted in a specific way. Thanks to windows, these files can sometimes contain values like 1.#INF or 1.#IND or even 1.#QNAN. As you can see these are window's own versions of Inf and NaN. These can also be negative.

I was able to produce an NaN value which Octave recognized as NaN with:
double nan = std::numeric_limits<long double>::quiet_NaN();

However, double inf = std::numeric_limits<long double>::infinity(); was interpreted somewhere as meaning NaN as well instead of inf.

Does anyone have any suggestions as to how to correct this?

Nevermind all of this. The problem was due to an issue with strcmp and never getting to the inf part. The code does work as it should with Octave, though my example has some casting issues and is missing an include statement.