Behaviour when formatting a NaN to a string with a %d specifier

[Mads]

Chasing down a bug where some strange values appeared I found that the culprit was a conversion from float to string where the format specifier was %d. The format code had been chosen as a quick way to round the number to an integer...but with the float value being NaN the string became "9223372036854775807". The fix was simple enough; just change the format specifier to %.0f, but it got me thinking that this is not the optimal parsing strategy 😮

We are allowed to do this in LabVIEW - parse a float into a string using the format specifier of an integer %d and this might seem like a quick way to round the float to the nearest integer in the same operation, but the catch is that if the float has a NaN value the outcome is not properly defined. This is the case in other programming languages as well, some will output 0, others will output the same as G/LabVIEW...

It could be argued though that the fact that you want a string representation that *can* represent NaN should trump the fact that you are requesting the conversion to interpret it as an integer. The string *is* able to convey the original NaN, and the fact that integers happen to lack that ability is rarely useful in this context. As long as %d is supported on floats (not returning an error as in some languages), it seems better to output the string "NaN" in most cases; It retains the information better than the "9223372036854775807" value.

Such a change might break code which for some reason relies on the current behaviour though so making it an option in the Edit format string Options might be the nearest backwards compatible solution....but then it would really just replace the code, and that change might as well just be %.0f, but even that could at least help users detect that their original train of though had an unresolved (now solved) issue...

[altenbach]

Interesting. Seems that in some cases it first converts the NaN o I64, and in other cases not. (same happens with "Inf")

Seems a bit inconsistent...

[paul_a_cardinale]

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

Decades ago, I read somewhere (but can't find now) that the "standard"  for representing "indefinite" with integer formats was to have the MSB set and the remaining bits be 0's.  For a 64-bit number that would be "8000000000000000" hexadecimal or "-9223372036854775808" decimal.

[altenbach]

---

@paul_a_cardinale wrote:

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

---

An U64 can be 2x larger than that (18446744073709551615). You probably meant largest signed integer.

You cannot represent NaN, Inf,-Inf with any integer, else the wraparound math would not work at all. Do you have a supporting link for your statement?

(Of course in a "local" application, we can define a sentinel value that should never occur in regular use as having special meaning)

[Martin_Henz]

I have occasionally suspected that the coercion dot is incorrect. At "Number to Decimal" LabVIEW claims to convert the double into an integer, which is not correct. There is no conversion to an integer. 

[rolfk]

---

@paul_a_cardinale wrote:

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

Decades ago, I read somewhere (but can't find now) that the "standard"  for representing "indefinite" with integer formats was to have the MSB set and the remaining bits be 0's.  For a 64-bit number that would be "8000000000000000" hexadecimal or "-9223372036854775808" decimal.

---

It's definitely not a "standard". A convention maybe, in the context of a certain framework or device.

Standards are things like IEEE-754 that define floating point values and their representation and even those allow some interpretation that are usually addressed in subsequent revisions.

[Andrey_Dmitriev]

---

@rolfk wrote:

---

@paul_a_cardinale wrote:

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

Decades ago, I read somewhere (but can't find now) that the "standard"  for representing "indefinite" with integer formats was to have the MSB set and the remaining bits be 0's.  For a 64-bit number that would be "8000000000000000" hexadecimal or "-9223372036854775808" decimal.

---

It's definitely not a "standard".

---

Hmmm....

"In the IEEE 754 binary interchange formats, NaNs are encoded with the exponent field filled with one...

For example, an IEEE 754 single precision (32-bit) NaN would be encoded as

s111 1111 1xxx xxxx xxxx xxxx xxxx xxxx

where s is the sign (most often ignored in applications) and the x sequence represents a non-zero nu..."

"

[altenbach]

---

@Andrey_Dmitriev wrote:

---

@rolfk wrote:

---

@paul_a_cardinale wrote:

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

Decades ago, I read somewhere (but can't find now) that the "standard"  for representing "indefinite" with integer formats was to have the MSB set and the remaining bits be 0's.  For a 64-bit number that would be "8000000000000000" hexadecimal or "-9223372036854775808" decimal.

---

It's definitely not a "standard".

---

Hmmm....

"

---

Integers don't have an exponent field. Only floating point representations do. For integers, all bits have equal rights. 😄

NaN and Inf coerce to the highest possible integer value and -Inf to the lowest. The same is true for all integer representations.

[Andrey_Dmitriev]

---

@altenbach wrote:

---

@Andrey_Dmitriev wrote:

---

@rolfk wrote:

---

@paul_a_cardinale wrote:

As a side note, "9223372036854775807" in hexadecimal is "7FFFFFFFFFFFFFFF" which the largest (most positive) number representable with 64 bits.

Decades ago, I read somewhere (but can't find now) that the "standard"  for representing "indefinite" with integer formats was to have the MSB set and the remaining bits be 0's.  For a 64-bit number that would be "8000000000000000" hexadecimal or "-9223372036854775808" decimal.

---

It's definitely not a "standard".

---

Hmmm....

"

---

Integers don't have an exponent field. Only floating point representations do. For integers, all bits have equal rights. 😄

---

Yes, I am referring to floating-point numbers, not integers. 7FFF... is the standard and represents the standard NaN value. This is why I always recommend learning a strictly typed programming language first before diving into LabVIEW.

fn main() {
    println!("Hello, NAN!");
    let nan = f64::NAN;
    let converted = nan as i64;
    let nan_bits = nan.to_bits();
    let as_i64 = nan_bits as i64;
    println!("f64::NAN: {}    (bits: {:064b})", nan, nan_bits);
    println!("Converted i64: {} (bits: {:064b})", converted, converted);
    println!("Converted i64 bits:     {:064b}", as_i64);
    println!("Decimal representation: {} (0x{:X})", as_i64, as_i64);
}

and result:

Hello, NAN!
f64::NAN: NaN    (bits: 0111111111111000000000000000000000000000000000000000000000000000)
Converted i64: 0 (bits: 0000000000000000000000000000000000000000000000000000000000000000)
Converted i64 bits:     0111111111111000000000000000000000000000000000000000000000000000
Decimal representation: 9221120237041090560 (0x7FF8000000000000)

and in LabVIEW: 😄

[softball]

Hi

NaN is truly fascinating. One could surely write a ( little ) book about its use.

I just wanted to mention a recent thread related to comparing numbers :

Comparing Clusters with NaN elements

Regards