Hello again,

I discovered a couple more things is_numeric... is causing problems with
(leading whitespace).  I doubt any of the examples I've given make sense to
regular users who don't know what's happening behind the scenes.  Add these
to the "wrong" list:

is_numeric(' .123') // bool(false)
' .123' + 0 // int(0)


One more thing I was curious about as far as keeping things consistent is
with is_numeric... (and therefore convert_scalar_to_number()), hex strings
are allowed/work, but not with convert_to_[long|double]().  So a few PHP
functions properly accept hex strings, but most will convert one to 0.
Should anything be done about this difference?  I have an idea about
allowing hex strings in to_[long|double] using the new is_numeric...
functions I will propose.

Few things about the current is_numeric... and hex strings, which I think
I'll change in my proposal unless I hear opinions otherwise:
*) Leading whitespace isn't allowed
*) A sign (±) isn't allowed
*) Hex doubles don't work.  I think they should (for *whole* numbers only
obviously, no ".").  So '0xFFFFFFFFFF' + 0 for example, works on a 32-bit
system.

If that last one can be changed, it also should be in the language parser of
course (you know, for $n = 0xFFFFFFFFFF;).


Thanks,
Matt


----- Original Message -----
From: "Matt W"
Sent: Sunday, August 06, 2006

> Hi all,
>
> Since I've been looking at is_numeric_[string|unicode], I found a weird
> thing it causes; probably doesn't make sense to users; bug?  Look:
>
> abs(-1e500) // float(INF)
> abs('-1e500') // int(1)  WRONG
> abs('-1e100') // float(1.0E+100)
> is_finite(1e500) // bool(false)
> is_finite('1e500') // bool(true)  WRONG
> is_finite('1e100') // bool(true)
> is_numeric(1e500) // bool(true)
> is_numeric('1e500') // bool(false)  WRONG
> is_numeric('1e100') // bool(true)
> 1e500 + 123 // float(INF)
> '1e500' + 123 // int(124)  WRONG
>
> You get the idea.  That's because is_numeric_string() *ignores* the value
> from zend_strtod() if errno==ERANGE.  I don't think that's right, and it
> doesn't happen when convert_to_double() uses zend_strtod():
>
> number_format(1e500) // string(3) "inf"
> number_format('1e500') // string(3) "inf"  RIGHT
>
> Just wondering if others think is_numeric_string() should be changed in
that
> respect?  I was going to rewrite the function to improve/optimize it (and
> submit it of course), so I can easily change its behavior while I'm at
it...
>
> Also, is this the desired behavior of array_count_values() (manual doesn't
> say; it also uses is_numeric...)?
>
> print_r(array_count_values(array(1, '   1', '  1  ')))
> Array
> (
>     [1] => 2
>     [  1  ] => 1
> )

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to