strtod and NaN vs. zero

Am 23.10.2016 um 21:13 schrieb Marc Bennewitz:

Am 23.10.2016 um 13:49 schrieb Niklas Keller:

2016-10-23 12:55 GMT+02:00 Marc Bennewitz <dev@mabe.berlin
mailto:dev@mabe.berlin>:

Hi internals,

On casting a non numeric value to a float in PHP the result will be
float(0).

In PHP-7.0 an exception was introduced that on casting a string
"/\s*NaN\s*/i" will result in float(NaN).

https://3v4l.org/2Xakm

Wouldn't it be more logical and expected to return NaN in all cases
of casting a non numeric string to a floating point number?

Thanks
Marc

--

+1

I just noticed that the behavior change in PHP-7 has been "fixed"
already by https://bugs.php.net/bug.php?id=73329.

So the old behavior will be presented soon.

But I'm still curious why casting any non numeric string results in the
valid number float(0) where there is a special value in floating point
numbers declared to represent not a number values.

I also did a small research on other languages and found the following:

C strtod returns float(0)
-> but supports converting the strings "INFINITY" or "NAN"
(case-insensitive)

JavaScript returns NaN

I forgot to mention that in JavaScript (parseFloat) it is nearly the
behavior I would expect. The only difference is that it allows the
string +/- "Infinity" to be casted to Infinity.

Python throws ValueError: could not convert string to float
-> but supports the string +/- "NaN", "Inf", "Infinity"
(case-insensitive)

Perl returns float(0)
-> but supports the string +/- "NaN", "Inf", "Infinity"
(case-insensitive)

So there is a nice mix of how other languages will handle this problem.

In my opinion it still makes much more sense to return NaN in any case a
not numeric string will be casted to float incl. "Inf" and "Infinity".
(If spaces should be ignored or suffixes allowed is another question)

= The beginning of a string must contain at least one number by ignoring
spaces to be casted to a valid floating point number. In any other
situations NaN must be returned because this represents what it is = Not
a Number.

So for me the following example table makes sense:

In -> Out
"" -> NaN
" " -> NaN
"+" -> NaN
"-" -> NaN
"." -> NaN
".5" -> 0.5
"0.5" -> 0.5
" 0.5" -> 0.5
"0" -> 0
" 0" -> 0
"Nan" -> NaN
"Inf" -> NaN
"Info" -> NaN
"foo" -> NaN
".foo" -> NaN
".2foo" -> 0.2
" .2foo" -> 0.2
"foo1" -> NaN
"foo." -> NaN
"foo0.1" -> NaN

Thoughts
Marc

Regards, Niklas

Hi,

Marc Bennewitz wrote:

But I'm still curious why casting any non numeric string results in the
valid number float(0) where there is a special value in floating point
numbers declared to represent not a number values.

Because that's what C's strtod() does, and it's also what (int) does
(because that's what C's strtol()) does.

There'd be an argument for using NaN, sure, but it wouldn't be
consistent with the rest of the language. Generally, PHP assumes that a
string with no leading digits has the number value of zero. This is true
not only in (int) and (float) casts, but also in generic number coercion
operations, like with +, -, *, / and **. To change the behaviour of
(float) here would be to introduce a new inconsistency to PHP. If we go
for NaN everywhere, then we introduce a different problem: (int) should
return an integer, and the generic number coercions prefer giving you an
integer rather than a float if appropriate. Producing a NaN here would
mean you'd now get an int rather than a float, and would cause a
cascading change in operation result types which could lead to
previously working code now throwing lots of E_WARNINGs or TypeErrors
(NaN is not accepted for integer type declarations in weak mode, and all
floats are not accepted for integer type declarations in strict mode).

Thanks.

--
Andrea Faulds
https://ajf.me/