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

[altenbach]

NaN can be endless fun, because there are so many possible bit patterns that represent it.

This thread has plenty of examples. 😄

[Andrey_Dmitriev]

My own funny trick how to replace zeroes to NaNs if needed for some computations:

[rolfk]

---

@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....

"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..."

"

---

As Christian already pointed and and as I'm very aware, floating point values are very standardized about what bit patterns represent Nan, Inf, and -Inf. My remark was in response to the mentioning that there exists a standard to represent NaN when using Integers. It doesn't but I have seen devices that use a special value, usually the MSB set or all bits set. And here lies the crux, everybody does their own thing, so very far from a standard. Logically I would consider the use of any bit pattern in an integer as NaN at best confusing.

[Andrey_Dmitriev]

---

@rolfk wrote: As Christian already pointed and and as I'm very aware, floating point values are very standardized about what bit patterns represent Nan, Inf, and -Inf. My remark was in response to the mentioning that there exists a standard to represent NaN when using Integers. It doesn't but I have seen devices that use a special value, usually the MSB set or all bits set. And here lies the crux, everybody does their own thing, so very far from a standard. Logically I would consider the use of any bit pattern in an integer as NaN at best confusing.

---

Ah, sorry — I read your comment too quickly and "diagonally". Indeed, there is currently no widely adopted math library or programming language that defines NaN for integers in the same way it's defined for floating-point numbers, where NaN is a built-in value and this obviously impossible. However, some libraries handle undefined/missing values for integers through other mechanisms.

For example, Pandas uses its experimental pd.NA and can represent integer data with missing values via IntegerArray

In Rust we can use nullable types like Option<i32> to represent undefined states explicitly, requiring developers to define safe fallback values during casting:

rustfn parse_integer(input: &str) -> Option<i32> {
    match input.parse() {
        Ok(value) => Some(value),
        Err(_) => None,  // Undefined state for invalid input
    }
}

fn process_number(maybe_num: Option<i32>) -> f32 {
    match maybe_num {
        Some(n) => n as f32,  // Convert valid integer to float
        None => f32::NAN,      // Use NaN for undefined state
    }
}

fn main() {
    let valid = parse_integer("42");
    let invalid = parse_integer("not_a_number");

    println!("Valid: {}", process_number(valid));   // 42.0
    println!("Invalid: {}", process_number(invalid)); // NaN

    // Working with Option<i32> directly
    if let Some(value) = valid {
        println!("We have a valid value: {}", value);
    }

    // Using unwrap_or for default values
    let safe_value = invalid.unwrap_or(i32::MIN);
    println!("Safe value: {}", safe_value);  // -2147483648
}

then

Valid: 42.0
Invalid: NaN
We have a valid value: 42
Safe value: -2147483648

Generally speaking, for invalid integer operations (e.g., division by zero), traditional programming languages typically raise errors rather than returning special values like NaN, such as «attempt to divide [value] by zero». LabVIEW remains silent in this regard:

[Mads]

This trailed off a bit, so to return to the original topic:

It would make more sense if the two circled cases did the same thing, preferably both outputting NaN. It conveys the most information and is allowed by the target type (string).