in reply to Re^6: Weird behavior of int()
in thread Weird behavior of int()

Your particular trunc might have that behaviour, but trunc general might not.

The spec simply describes trunc as follows:

The trunc functions round their argument to the integer value, in floating format, nearest to but no larger in magnitude than the argument.

The spec simply describes what it returns as follows:

The trunc functions return the truncated integer value.

Passing an infinity or a NaN is therefore undefined behaviour. Anything could happen.

Replies are listed 'Best First'.
Re^8: Weird behavior of int()
by pryrt (Abbot) on May 21, 2024 at 23:38 UTC
    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.

[reply]
[d/l]
[select]

      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]
        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]

In Section Seekers of Perl Wisdom