is_finite, is_infinite, is_nan wrong input type argument

[remco-pc]

Description

The following functions

• is_finite,
• is_infinite,
• is_nan
  have the argument as a float.
  I believe float ranges are smaller then integer ranges (so is_finite kicks in earlier on a float then on an integer (where the last one is not possible yet))
  Also i believe these functions should accept mixed (like is_int & is_float use) and should convert a numeric string to an integer or a float (wheter it has a comma or not).

this all for the easier way of writing it in templating string like

{{$number = '1.1'}}
{{$is.int.result = $number|is.int}} //false
{{$is.float.result = $number|is.float}} //false
{{$is.number = $number|is.number}} //true
{{$is.finite = $number|is.finite}} //error but custom method could convert numbers it to float (recoverable)
{{$is.infinite = $number|is.infinite}} //error but custom method could convert numbers it to float (recoverable)
{{$is.nan = $number|is.nan}} //error but custom method could convert numbers it to float (recoverable)
{{$is.float.finite = $number|cast.float|is.finite}} //possible
{{$is.float.infinite = $number|cast.float|is.infinite}} //possible
{{$is.float.nan = $number|cast.float|is.nan}} //possible
{{$is.int.finite = $number|cast.integer|is.finite}} //possible due to custom calculation with PHP_INT_MAX & MIN
{{$is.int.infinite = $number|cast.integer|is.infinite}} //possible due to custom calculation with PHP_INT_MAX & MIN
{{$is.int.nan = $number|cast.integer|is.nan}} //possible due to custom calculation with PHP_INT_MAX & MIN

PHP Version

php8.3.15

Operating System

Debian 12

[damianwadley]

I believe float ranges are smaller then integer ranges

No, floats have a much larger range than integers (though they begin losing accuracy at a certain point).

so is_finite kicks in earlier on a float then on an integer

"Kicks in"?

(where the last one is not possible yet)

Every integer is always finite, never infinite, and never NaN. Because "infinite" and "NaN" correspond to very specific IEEE definitions that only apply to floating-point numbers.

Saying it's not possible "yet" implies that it could ever be, but there's really no reason to believe that will ever happen.

Also i believe these functions should accept mixed (like is_int & is_float use)

Those functions have completely different use cases: is_finite/infinite/nan test whether certain floating-point numbers qualify as INF or NAN or not, noting that you can do === INF but you cannot do === NAN, while is_int/float/etc are used to test the type of a variable's value. It does not make sense to provide (non-numeric) strings, objects, arrays, or resources to the is_finite/etc functions because those things are not even numbers to begin with.

and should convert a numeric string to an integer or a float

If strict_types is not active then this is already supported naturally by PHP's loose typing system.

(wheter it has a comma or not)

You're free to bring up allowing commas in string->number conversions on the PHP internals list, but I can all but guarantee there will not be much support for it. In fact PHP has gone through some effort to make sure that doesn't happen.

If you want a way to convert a locale-formatted numeric string to a number then I suggest checking if the intl extension has something that can do it.

{{$is.finite = $number|is.finite}} //error

As mentioned, PHP fully supports string values as parameters to those functions, but not when using strict_types. So if you're getting a "argument must be of type float, string given" error then that means your templating engine is using strict_types (which also means you may have similar problems with many other functions). Or perhaps it implements its own custom support for that functionality instead of directly using the is_* functions.

All in all, everything here appears to be behaving as expected: the three functions support floats and integers (even though all integers are always finite), they support numeric strings (if strict_types is not enabled), and they do not support the other data types (because apples are not oranges).

[iluuu1994]

"Kicks in"?

Please don't do that. English is not everybody's first language, and mocking them for it is not productive or welcoming.

But as Damian mentioned, nan, inf and -inf are all IEEE-754 concepts. They are not a thing for integers.

If you want a more lax function that accepts ints and always returns false for them, creating a wrapper function would be trivial.

[remco-pc]

@damianwadley,

i believe that an integer between PHP_INT_MIN and PHP_INT_MAX constants are considered finite, anything else would be infinite / out of range also for nan, between the constants PHP_INT_MIN and PHP_INT_MAX a integer is considered a number, outside these a nan ?

[iluuu1994]

@remco-pc There are no values below PHP_INT_MIN and above PHP_INT_MAX. On most CPUs, over-/underflowing integers simply wraps to the other end of the range, i.e. INT_MAX + 1 becomes INT_MIN and INT_MIN - 1 becomes INT_MAX. There is no bit-pattern to represent nan, inf, -inf, etc. IEEE-754 floats on the other hand have such dedicated bit-patterns, which is why is_nan and friends specifically only make sense for float values. This is the reason isnan in C itself does not offer an integer variant, because every integer is by definition not a nan.

[github-actions]

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.