QString::number returns NaN, but only after compilation

drew_hamilton

Here's a strange one.

I have a bit of code that keeps track of RX/TX serial communication speeds. I am updating a float ''RX_freq_hz'' using a signal-slot mechanism from my serial interface. When I run this code in both Debug and Release from within the QT IDE, I am reading out the values properly, but after compilation to EXE on windows, QString::number seems to be returning NaN.

There's not much to the code, it looks something like this:
QString RX_freq_hz_readout;
if (RX_freq_hz < 1000) {RX_freq_hz_readout = QString::number(RX_freq_hz, 'f', 2) + " Hz";}
else {RX_freq_hz_readout = QString::number(RX_freq_hz / (float)1000, 'f', 2) + " kHz";}

Output is "RX: nan kHz" and "TX: nan kHz"

Any ideas!? Everything else in this rather involved bit of code works wonderfully.

Thanks in advance.

JonB

@drew_hamilton said in QString::number returns NaN, but only after compilation:

Output is "RX: nan kHz"

Why not print RX_freq_hz so you can evaluate why RX_freq_hz / (float)1000 is causing nan?

drew_hamilton

This post is deleted!

drew_hamilton

@JonB @JonB I can print it out with qDebug, and it's something like 68.23 Hz. But if I compile it, I'm not logging the debug output, I'm just displaying it via this QString::number conversion on a toolbutton.

Christian Ehrlicher

@drew_hamilton said in QString::number returns NaN, but only after compilation:

. But if I compile it,

What does this mean? Do you remove the line when you compile it in release mode? Simply don't do it and check the value then.

KroMignon

@drew_hamilton said in QString::number returns NaN, but only after compilation:

I can print it out with qDebug, and it's something like 68.23 Hz. But if I compile it, I'm not logging the debug output, I'm just displaying it via this QString::number conversion on a toolbutton.

I am not sure to understand what you are doing. What is the type of RX_freq_hz?
I guees it is an int.
I would change your code to:

QString RX_freq_hz_readout = (RX_freq_hz < 1000) ? 
    QString("%1 Hz").arg(RX_freq_hz) :
    QString("%1 kHz").arg(float(RX_freq_hz)/1000, 0, 'f', 2);

JonB

@drew_hamilton said in QString::number returns NaN, but only after compilation:

QString::number(RX_freq_hz / (float)1000, 'f', 2)

QString::number((double)RX_freq_hz / 1000.0, 'f', 6)
QString::number((double)RX_freq_hz / 1000.0, 'e', 6)

Copy & paste, do either of those show any better?

All I originally wanted you to do was report what

QString::number(RX_freq_hz, 'f')`

showed when you get the nan result.

drew_hamilton

I tried KroMignon's more elegant way of coding this, and the results are the same. I'm not sure if I was being clear enough in my question. If I run this code in the QT IDE in either Release or Debug, the values show as numbers. If I run a standalone EXE that I have compiled, it shows as NaN.

The variables RX_freq_hz and TX_freq_hz are both floats.

Here you can see this is the same code, run first in the IDE:
alt text

And again, as a standalone executable:
alt text

Christian Ehrlicher

@KroMignon said in QString::number returns NaN, but only after compilation:

RX_freq_hz

So since this is nan, find out where it comes from and add debug output there.

drew_hamilton

@Christian-Ehrlicher Forgive my ignorance. How would I do this as a standalone executable? Would I have to setup a debug logging system? When I run this in the IDE, the float is a number. I initialize it as a public variable with the value of 666, just for giggles. I'm not sure how to track this down given that it only happens in a context in which I don't have the Application Output window.

In a moment of desperation, I tried running it from Command Prompt thinking that it would display the debug output. Very interestingly, the number does not show up as nan if run from the command line. It shows up correctly.

Meaning there is something happening that is very specific to the context in which the executable is launched.

Christian Ehrlicher

@drew_hamilton said in QString::number returns NaN, but only after compilation:

In a moment of desperation, I tried running it from Command Prompt thinking that it would display the debug output. Very interestingly, the number does not show up as nan if run from the command line. It shows up correctly.

This means you've an uninitialized variable somewhere which leads to your nan.

Would I have to setup a debug logging system?

Simple QMessageBoxes will do it too, or use qWarning() and let it print to the console.

drew_hamilton

@Christian-Ehrlicher How could a variable be uninitialized when run from File Explorer and initialized when run from the command prompt?

Christian Ehrlicher

@drew_hamilton said in QString::number returns NaN, but only after compilation:

How could a variable be uninitialized when run from File Explorer and initialized when run from the command prompt?

You said in debug mode it's fine so it can be that the memory the variable points to is initialized to a usable value, in release mode it's not. So it's a common uninitialized variable problem.

JonB

@Christian-Ehrlicher
While it does sound like an uninitialized, the OP actually wrote earlier:

If I run this code in the QT IDE in either Release or Debug, the values show as numbers. If I run a standalone EXE that I have compiled, it shows as NaN.

I think he's saying any version works from IDE, no version outside.

I guess random memory contents could differ when run in those two cases. Otherwise maybe the environment is different for whatever measurements they do to collect the figures.

@drew_hamilton
If it is an uninitialized variable really you have to track it down.

drew_hamilton

@JonB Correct.

@Christian-Ehrlicher The variable is initialized as 666, just to make sure it has SOME value to begin with. It is initialized in public section of my MainWindow class. This doesn't seem to be enough (when running as a standalone executable from File Explorer). If I overwrite the value directly before generating my QString, it will of course use that value. This means that somehow this variable is not initialized by my class, but only in the context of running the executable from File Explorer. It is initialized when run from the IDE and when run from the Command Prompt as a standalone executable.

Surely you can understand why I am scratching my head.

The initialization happens something like this:

class MainWindow : public QMainWindow
{
Q_OBJECT

public:
MainWindow(QWidget *parent = nullptr);
~MainWindow();

void setup_layout_for_serialComs();

... blah blah...

 float RX_freq_hz = 666;
 float TX_freq_hz = 666;

JonB

@drew_hamilton
But the question is what happens to this RX_freq_hz from now on. We assume it's updated all the time? If that calculation make it become nan because of some issue elsewhere. I assume if you left it at 666 and never updated it it would never show as nan!?

Use bool qIsNaN(double d) immediately before you go QString::number(RX_freq_hz), or whatever you display. I assume that returns true when nan is displayed. Then it's not a QString::number() issue, it's the value for sure. Wherever that comes from.

Christian Ehrlicher

@drew_hamilton said in QString::number returns NaN, but only after compilation:

It is initialized in public section of my MainWindow class.

But you modify it somewhere and access an uninitialized value there.

drew_hamilton

@Christian-Ehrlicher I'm wondering how it would be possible to put a NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767. Maybe I misunderstand something about how that works.

Christian Ehrlicher

@drew_hamilton said in QString::number returns NaN, but only after compilation:

NaN value into a float as it is just 4 bytes. Assuming the variable EXISTS, anything you put into it should be between -32767 and 32767.

Ok, now please go back to the basics... float is not an integral number...

drew_hamilton

@Christian-Ehrlicher Right, I guess what im saying is that any arbirtrary arrangement of bits that as up to four bytes should be a valid number of some kind, right?