Re^8: Weird behavior of int()

The spec

Which spec?

Unless I read this wrong, at least IEEE Std 1003.1-2017 (ie, the POSIX standard) defines NaN and Inf behavior for trunc . As did the older IEEE Std 1003.1-2008 edition.

And while not every implementation will follow POSIX, I don't feel I am wrong in expecting that following the behavior in an IEEE standard is reasonable behavior. And if it's reasonable behavior, then I don't feel I was wrong in arguing that the behavior makes sense for perl's int as well.

(And from what I remember of IEEE754 -- though it's been a while since I've read the relevant portions -- NaN was supposed to propagate if you try to do the various mathematical operators or functions on it. So my argument is in keeping with the spirit of that spec (at least as far as I remember it).)

update: I looked it up when I got to work the next day. IEEE 754-2008 section 6.2 "Operations with NaNs": "For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs." And in 6.2.3 "NaN Propagation": "An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a NaN with the payload of the input NaN if representable in the destination format." Floating-point NaNs are intended to propagate.

Comment on Re^8: Weird behavior of int() Select or Download Code

Replies are listed 'Best First'.
Re^9: Weird behavior of int() by ikegami (Patriarch) on May 22, 2024 at 14:12 UTC
We're talking about the C's `trunc`, so the C spec. (I specifically quoted C18, but I bet it's the exact same words since 89.)	[reply] [d/l]
Re^10: Weird behavior of int() by pryrt (Abbot) on May 22, 2024 at 17:10 UTC
Thank you for clarifying. However, whether or not all `trunc` implementations do it that way, it doesn't change my main points: preserving INF and NAN through an operation like perl's `int` is reasonable. I was using the example of POSIX-compliant `trunc` , not because I was saying "since `trunc` requires this behavior (which you have pointed out is not true), then perl's `int` must behave this way", but because I was saying "since something like POSIX's implementation of `trunc` implements it this way, I believe it is reasonable to implement such functions this way, whether it's an implementation of `trunc` or of perl's `func` or any other similar "return the integer portion of a number that might have a non-integer component" function.	[reply] [d/l] [select]