QString::number returns NaN, but only after compilation

[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:

And again, as a standalone executable:

[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?

[Christian Ehrlicher]

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

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?

No, float is a IEEE-754 floating point number.

And now please go to all places where you modify this value and check them. Esp. if you e.g. divide by 0 for accident or similar.

[mranger90]

You get that number from "Somewhere", right ? Maybe an external device or library ?
If it doesn't work when executed outside of the IDE, then I would suspect some kind of race condition or hiccup when communicating with the device in that the timing has changed. In which case you are getting garbage bits that don't conform to a floating point number.

[drew_hamilton]

I found a variable feeding this number that was not initialized with a value and this got rid of the issue. Still really scratching my head as to why it's not initialized in different contexts.

[JonB]

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

I found a variable feeding this number that was not initialized with a value and this got rid of the issue.

There you are, as we ( @Christian-Ehrlicher) suggested!! Aren't you pleased you have tracked a nasty bug down?!

(BTW, do you have all compiler warnings on? You ought to. These days compilers are pretty good at telling you when they see a potentially-uninitialized variable used, but depends on your usage in code.)

Still really scratching my head as to why it's not initialized in different contexts.

It is never "initialized" in any context, since you have said it's "not initialized with a value" by your code. In that case, say it's on the stack (e.g. local variable), its value will be whatever happens to be in that memory location at the time. And, simply put, that can vary across builds, build-types, environments run from, time of day, or weather. You were "lucky" it ever worked OK, you may never find a pattern which tells you what its value was or why it varied.