Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #9264 > unrolled thread
| Started by | fred <email@address.com> |
|---|---|
| First post | 2013-05-12 15:22 +0100 |
| Last post | 2013-05-15 13:11 +0200 |
| Articles | 20 on this page of 141 — 20 participants |
Back to article view | Back to comp.lang.php
bug in is_numeric fred <email@address.com> - 2013-05-12 15:22 +0100
Re: bug in is_numeric Salvatore <sal@yojimbo.hack.invalid> - 2013-05-12 15:31 +0000
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 17:55 +0200
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 17:58 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-12 18:06 +0200
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-12 16:24 +0000
Re: bug in is_numeric fred <email@address.com> - 2013-05-12 18:41 +0100
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-13 13:50 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-13 14:58 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 10:11 -0400
Re: bug in is_numeric fred <email@address.com> - 2013-05-13 15:15 +0100
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-13 17:29 +0200
Re: bug in is_numeric "J.O. Aho" <user@example.net> - 2013-05-13 19:55 +0200
Re: bug in is_numeric Richard Yates <richard@yatesguitar.com> - 2013-05-14 06:41 -0700
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-14 21:43 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-14 23:01 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-15 05:48 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-15 06:11 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:36 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 15:19 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 20:23 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 20:49 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 21:58 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 22:20 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 22:42 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-15 23:53 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-16 00:29 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-16 00:40 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-16 05:00 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:16 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 00:45 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 22:52 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 18:33 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-17 20:39 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 23:45 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-18 14:47 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-15 20:57 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-16 00:09 -0400
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-17 01:17 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-16 20:30 -0400
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-18 14:51 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 10:07 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 11:56 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 14:32 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 22:24 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 17:01 -0400
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-18 21:58 +0000
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:21 -0400
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-19 02:22 +0000
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 22:41 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:28 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:42 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:42 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:39 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 01:01 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 05:59 -0400
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 07:49 +0100
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:31 -0500
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 12:39 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:43 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:52 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:42 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 01:03 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:00 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:45 -0500
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:27 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:45 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:37 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:43 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 00:59 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:02 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:08 -0500
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-18 23:58 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:22 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:11 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:23 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:35 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:46 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:23 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:44 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 00:54 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:03 -0400
Re: bug in is_numeric fred <email@address.com> - 2013-05-23 15:38 +0100
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-01 17:36 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-01 14:54 -0400
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 15:25 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 10:34 -0400
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 17:02 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 12:30 -0400
OT: What you say is not always what you mean (was: Re: bug in is_numeric) Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 20:20 +0200
Re: OT: What you say is not always what you mean Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 14:40 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 21:51 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:13 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-19 00:49 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:24 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-19 12:40 +0200
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 12:43 +0100
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:29 -0500
Re: bug in is_numeric Norman Peelman <npeelman@cfl.rr.com> - 2013-05-18 14:53 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:41 -0400
Re: bug in is_numeric Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-13 08:35 -0700
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-13 20:26 +0000
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-13 20:15 +0000
Re: bug in is_numeric Robert Heller <heller@deepsoft.com> - 2013-05-12 13:03 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 18:03 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-12 18:34 +0100
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:40 +0200
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 21:51 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-12 11:47 -0500
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 18:56 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-12 19:05 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:38 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:46 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 14:11 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 20:39 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 16:51 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 01:27 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 20:35 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 11:07 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 09:02 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 16:57 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 17:10 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 13:52 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 20:28 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:28 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 00:33 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 22:34 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 10:28 +0200
Re: bug in is_numeric Norman Peelman <npeelman@cfl.rr.com> - 2013-05-18 08:00 -0400
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-18 14:18 +0200
Re: bug in is_numeric Tim Streater <timstreater@greenbee.net> - 2013-05-18 13:20 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 08:47 -0400
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-18 14:05 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 10:16 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 16:14 +0200
Re: bug in is_numeric Sandman <mr@sandman.net> - 2013-05-14 10:34 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-14 14:47 +0100
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-14 14:54 +0000
Re: bug in is_numeric Sandman <mr@sandman.net> - 2013-05-15 08:05 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-15 06:27 -0400
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-15 13:11 +0200
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-15 20:23 +0200 |
| Message-ID | <kn0jok$ebm$1@speranza.aioe.org> |
| In reply to | #9351 |
Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> norman@amd64x2:~$ php -a
>> Interactive shell
>>
>> php > $a = 'x';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '11';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>> php > $a = 'x11.11c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '0x1111c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>>
>>
>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>
>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>> 0777) notation is allowed too but only without sign, decimal and
>> exponential part."
>
> But AISB, the implementation is contradicting the documentation (or vice-
> versa) because the a string argument containing the binary format causes
> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according to
> the above it should have returned TRUE).
I can confirm issues with is_numeric() wrt. strings in binary notation
in PHP 5.4.7:
>>> is_numeric('0b1010')
false
>>> is_numeric(0b1010)
true
> It is not possible to determine by
> testing whether the octal format is considered numeric because of itself or
> because it is considered decimal.
ACK
> Incidentally, you have neglected to test
> those two formats.
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-15 20:49 +0200 |
| Message-ID | <1934679.jXLOkI38UW@PointedEars.de> |
| In reply to | #9357 |
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> norman@amd64x2:~$ php -a
>>> Interactive shell
>>>
>>> php > $a = 'x';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> not okay
>>> php > $a = '11';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> okay
>>> php > $a = 'x11.11c';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> not okay
>>> php > $a = '0x1111c';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> okay
>>>
>>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>>
>>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>>> 0777) notation is allowed too but only without sign, decimal and
>>> exponential part."
>>
>> But AISB, the implementation is contradicting the documentation (or vice-
>> versa) because the a string argument containing the binary format causes
>> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according
5.4.15(-1; Debian), not .14
>> to the above it should have returned TRUE).
>
> I can confirm issues with is_numeric() wrt. strings in binary notation
> in PHP 5.4.7:
>
> >>> is_numeric('0b1010')
> false
> >>> is_numeric(0b1010)
> true
ACK. However, it is unsurprising to me that the latter would return TRUE
because there the literal is parsed into an “int” value *before* it is
passed to is_numeric(), the equivalent of is_numeric(10).
I would rather the former bug was an implementation bug instead of a
documentation bug, because such a function should either work for all
supported numeric representations of the programming language, or there
should be a parameter specifying which representations are supported for the
specific call [like ECMAScripts parseInt(number : String, base : Number) :
Number].
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-15 21:58 +0200 |
| Message-ID | <kn0pai$na$1@speranza.aioe.org> |
| In reply to | #9359 |
Thomas 'PointedEars' Lahn wrote:
> I would rather the former bug was an implementation bug instead of a
> documentation bug, because such a function should either work for all
> supported numeric representations of the programming language, or there
> should be a parameter specifying which representations are supported for the
> specific call [like ECMAScripts parseInt(number : String, base : Number) :
> Number].
ACK. However, the usefulness of is_numeric() returning true for strings
in binary notation is somewhat doubtful, as there is no simple way to
actually convert such strings to a number:
>>> (int) '0b1010'
0
>>> intval('0b1010')
0
>>> intval('0b1010', 2)
0
>>> 0 + '0b1010'
0
So the issue *might* as well be regarded as documentation bug.
BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-15 22:20 +0200 |
| Message-ID | <1622055.H2T55JCus4@PointedEars.de> |
| In reply to | #9362 |
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> I would rather the former bug was an implementation bug instead of a
>> documentation bug, because such a function should either work for all
>> supported numeric representations of the programming language, or there
>> should be a parameter specifying which representations are supported for
>> the specific call [like ECMAScripts parseInt(number : String, base :
>> Number) : Number].
>
> ACK. However, the usefulness of is_numeric() returning true for strings
> in binary notation is somewhat doubtful, as there is no simple way to
> actually convert such strings to a number:
>
> >>> (int) '0b1010'
> 0
> >>> intval('0b1010')
> 0
> >>> intval('0b1010', 2)
> 0
> >>> 0 + '0b1010'
> 0
>
> So the issue *might* as well be regarded as documentation bug.
ISTM to be strong indication that it is an implementation bug, where
the bug would be that the conversion from string to int is incomplete:
$ php -r 'var_dump(+"0x2A");'
int(42)
(as expected)
$ php -r 'var_dump(+"010");'
int(10)
(expected: 8)
A possibility for conversion is:
$ php -r 'var_dump(eval("return " . "0b1110" . ";"));'
int(14)
> BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
Bogus because binary numeric literals were introduced in PHP 5.4.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-15 22:42 +0200 |
| Message-ID | <kn0rte$8qb$1@speranza.aioe.org> |
| In reply to | #9363 |
Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> I would rather the former bug was an implementation bug instead of a
>>> documentation bug, because such a function should either work for all
>>> supported numeric representations of the programming language, or there
>>> should be a parameter specifying which representations are supported for
>>> the specific call [like ECMAScripts parseInt(number : String, base :
>>> Number) : Number].
>>
>> ACK. However, the usefulness of is_numeric() returning true for strings
>> in binary notation is somewhat doubtful, as there is no simple way to
>> actually convert such strings to a number:
>>
>> >>> (int) '0b1010'
>> 0
>> >>> intval('0b1010')
>> 0
>> >>> intval('0b1010', 2)
>> 0
>> >>> 0 + '0b1010'
>> 0
>>
>> So the issue *might* as well be regarded as documentation bug.
>
> ISTM to be strong indication that it is an implementation bug, where
> the bug would be that the conversion from string to int is incomplete:
>
> $ php -r 'var_dump(+"0x2A");'
> int(42)
>
> (as expected)
>
> $ php -r 'var_dump(+"010");'
> int(10)
>
> (expected: 8)
Interestingly the type cast to int has another result:
$ php -r 'var_dump((int) "0x2A");'
int(0)
In bug report #52950[1] the latter behavior is reported as expected.
IMO the former behavior is more useful and consistent. Anyway, the
explicit type cast and the implicit type juggling should have the same
result.
> A possibility for conversion is:
>
> $ php -r 'var_dump(eval("return " . "0b1110" . ";"));'
> int(14)
Ugly, but effective.
>> BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
>
> Bogus because binary numeric literals were introduced in PHP 5.4.
I wasn't aware of that. Thanks for pointing it out.
[1] <https://bugs.php.net/bug.php?id=52950>
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2013-05-15 23:53 +0200 |
| Message-ID | <kn1054$ck1$1@news.albasani.net> |
| In reply to | #9362 |
Christoph Becker schrieb:
> ACK. However, the usefulness of is_numeric() returning true for strings
> in binary notation is somewhat doubtful, as there is no simple way to
> actually convert such strings to a number:
>
> >>> (int) '0b1010'
> 0
> >>> intval('0b1010')
> 0
> >>> intval('0b1010', 2)
> 0
> >>> 0 + '0b1010'
> 0
bindec( '0b1010' )
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-16 00:29 +0200 |
| Message-ID | <kn1278$qpf$1@speranza.aioe.org> |
| In reply to | #9371 |
Thomas Mlynarczyk wrote:
> Christoph Becker schrieb:
>> ACK. However, the usefulness of is_numeric() returning true for strings
>> in binary notation is somewhat doubtful, as there is no simple way to
>> actually convert such strings to a number:
>>
>> >>> (int) '0b1010'
>> 0
>> >>> intval('0b1010')
>> 0
>> >>> intval('0b1010', 2)
>> 0
>> >>> 0 + '0b1010'
>> 0
>
> bindec( '0b1010' )
Nice -- thanks for pointing it out. :)
But what's that:
>php -r "var_dump(bindec('foo1010bar'));"
int(10)
It seems bindec() ignores any leading and trailing characters that are
neither 0 or 1.
So, bindec() doesn't seem to be useful for a routine, which would
convert an arbitrary numeric string to an integer.
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-16 00:40 +0200 |
| Message-ID | <kn12t7$sfe$1@speranza.aioe.org> |
| In reply to | #9372 |
Christoph Becker misquoted:
>> php -r "var_dump(bindec('foo1010bar'));"
> int(10)
Sorry for having used an > sign, which might be confused with a quote.
It should have been:
$ php -r 'var_dump(bindec("foo1010bar"));'
int(10)
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-16 05:00 +0200 |
| Message-ID | <36040878.qUTcmyb4oS@PointedEars.de> |
| In reply to | #9372 |
Christoph Becker wrote:
> Thomas Mlynarczyk wrote:
>> Christoph Becker schrieb:
>>> ACK. However, the usefulness of is_numeric() returning true for strings
>>> in binary notation is somewhat doubtful, as there is no simple way to
>>> actually convert such strings to a number:
>>>
>>> >>> (int) '0b1010'
>>> 0
>>> >>> intval('0b1010')
>>> 0
>>> >>> intval('0b1010', 2)
>>> 0
>>> >>> 0 + '0b1010'
>>> 0
>>
>> bindec( '0b1010' )
>
> Nice -- thanks for pointing it out. :)
ACK.
> But what's that:
>
> php -r "var_dump(bindec('foo1010bar'));"
> int(10)
>
> It seems bindec() ignores any leading and trailing characters that are
> neither 0 or 1.
>
> So, bindec() doesn't seem to be useful for a routine, which would
^
> convert an arbitrary numeric string to an integer.
True. But, on the other hand, it is not supposed to.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | SwissCheese <swisscheese@cfl.rr.com> |
|---|---|
| Date | 2013-05-16 18:16 -0400 |
| Message-ID | <kn3ljs$cqo$1@dont-email.me> |
| In reply to | #9359 |
On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> SwissCheese wrote:
>>>> norman@amd64x2:~$ php -a
>>>> Interactive shell
>>>>
>>>> php > $a = 'x';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> not okay
>>>> php > $a = '11';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> okay
>>>> php > $a = 'x11.11c';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> not okay
>>>> php > $a = '0x1111c';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> okay
>>>>
>>>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>>>
>>>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>>>> 0777) notation is allowed too but only without sign, decimal and
>>>> exponential part."
>>>
>>> But AISB, the implementation is contradicting the documentation (or vice-
>>> versa) because the a string argument containing the binary format causes
>>> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according
>
> 5.4.15(-1; Debian), not .14
>
>>> to the above it should have returned TRUE).
>>
>> I can confirm issues with is_numeric() wrt. strings in binary notation
>> in PHP 5.4.7:
>>
>> >>> is_numeric('0b1010')
>> false
>> >>> is_numeric(0b1010)
>> true
>
> ACK. However, it is unsurprising to me that the latter would return TRUE
> because there the literal is parsed into an “int” value *before* it is
> passed to is_numeric(), the equivalent of is_numeric(10).
>
> I would rather the former bug was an implementation bug instead of a
> documentation bug, because such a function should either work for all
> supported numeric representations of the programming language, or there
> should be a parameter specifying which representations are supported for the
> specific call [like ECMAScripts parseInt(number : String, base : Number) :
> Number].
>
>
> PointedEars
>
Thomas,
Looking into the source (PHP) there is no code to support binary
strings of the type '0b1010101'. The code for hexadecimal is there however.
php > $tests =
array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010","0b10101",
"10101010101010101010101010101010101010101010101010101010101010101010101010101010101010",
"0700");
php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is numeric
".var_dump(is_numeric($a)).PHP_EOL; } else { echo "$a is not
numeric".var_dump(is_numeric($a)).PHP_EOL; } }
bool(true)
42 is numeric
bool(true)
1337 is numeric
bool(true)
0xf4c3b00c is numeric
bool(false)
x11.11c is not numeric
bool(false)
0x11.11c is not numeric
bool(true)
0x1111c is numeric
bool(false)
0b1010 is not numeric
bool(false)
0b10101 is not numeric
bool(true)
10101010101010101010101010101010101010101010101010101010101010101010101010101010101010
is numeric
bool(true)
0700 is numeric
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-17 00:45 +0200 |
| Message-ID | <2571537.9COuFGnqet@PointedEars.de> |
| In reply to | #9393 |
SwissCheese wrote:
> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> to the above it should have returned TRUE).
>>>
>>> I can confirm issues with is_numeric() wrt. strings in binary notation
>>> in PHP 5.4.7:
>>>
>>> >>> is_numeric('0b1010')
>>> false
>>> >>> is_numeric(0b1010)
>>> true
>>
>> ACK. However, it is unsurprising to me that the latter would return TRUE
>> because there the literal is parsed into an “int” value *before* it is
>> passed to is_numeric(), the equivalent of is_numeric(10).
>>
>> I would rather the former bug was an implementation bug instead of a
>> documentation bug, because such a function should either work for all
>> supported numeric representations of the programming language, or there
>> should be a parameter specifying which representations are supported for
>> the specific call [like ECMAScripts parseInt(number : String, base :
>> Number) : Number].
>
> Thomas,
This is NetNews, not e-mail.
> Looking into the source (PHP) there is no code to support binary
> strings of the type '0b1010101'. The code for hexadecimal is there
> however.
AISB, testing with PHP does not help to resolve the basic issue here. From
such tests it is still unclear whether not supporting the binary format is
an implementation bug, i. e. an omission of supporting the binary format
introduced with PHP 5.4; or a documentation bug, i. e. manual claiming that
is_numeric() supports more than it is actually supposed to.
What would be interesting instead is to look at the source code from which
PHP 5.4 and particularly is_numeric() is built as that could at least show
if the octal format would be recognized, and if there was support for the
binary format that was just not properly triggered.
> [Tests]
This was so unnecessary. We have already ascertained how the implementation
works or rather how it does not work. Learn to read for a change, will you?
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
[toc] | [prev] | [next] | [standalone]
| From | SwissCheese <swisscheese@cfl.rr.com> |
|---|---|
| Date | 2013-05-16 22:52 -0400 |
| Message-ID | <kn45qg$ggn$1@dont-email.me> |
| In reply to | #9398 |
On 05/16/2013 06:45 PM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>>> Christoph Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> to the above it should have returned TRUE).
>>>>
>>>> I can confirm issues with is_numeric() wrt. strings in binary notation
>>>> in PHP 5.4.7:
>>>>
>>>> >>> is_numeric('0b1010')
>>>> false
>>>> >>> is_numeric(0b1010)
>>>> true
>>>
>>> ACK. However, it is unsurprising to me that the latter would return TRUE
>>> because there the literal is parsed into an “int” value *before* it is
>>> passed to is_numeric(), the equivalent of is_numeric(10).
>>>
>>> I would rather the former bug was an implementation bug instead of a
>>> documentation bug, because such a function should either work for all
>>> supported numeric representations of the programming language, or there
>>> should be a parameter specifying which representations are supported for
>>> the specific call [like ECMAScripts parseInt(number : String, base :
>>> Number) : Number].
>>
>> Thomas,
>
> This is NetNews, not e-mail.
>
Um, ok. So you chastise people about using real names yet don't want
yours used?
>> Looking into the source (PHP) there is no code to support binary
>> strings of the type '0b1010101'. The code for hexadecimal is there
>> however.
>
> AISB, testing with PHP does not help to resolve the basic issue here. From
> such tests it is still unclear whether not supporting the binary format is
> an implementation bug, i. e. an omission of supporting the binary format
> introduced with PHP 5.4; or a documentation bug, i. e. manual claiming that
> is_numeric() supports more than it is actually supposed to.
>
> What would be interesting instead is to look at the source code from which
> PHP 5.4 and particularly is_numeric() is built as that could at least show
> if the octal format would be recognized, and if there was support for the
> binary format that was just not properly triggered.
>
Isn't that what I just mentioned I did ('Looking into the source
code...') above? There is no support for binary numbers passed as
strings in the form '0b101010'. If you pass 0b101010 (not as a string)
and it gets converted to an (int) on the way in then that's obviously
not the same thing. And what is so special about octal that is_numeric()
would not recognise it?
>> [Tests]
>
> This was so unnecessary. We have already ascertained how the implementation
> works or rather how it does not work. Learn to read for a change, will you?
>
>
> PointedEars
>
Who is this 'PointedEars', get a real name will you?
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-17 18:33 +0200 |
| Message-ID | <1721337.cckPqGDC6N@PointedEars.de> |
| In reply to | #9402 |
SwissCheese wrote:
> On 05/16/2013 06:45 PM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Becker wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> to the above it should have returned TRUE).
>>>>>
>>>>> I can confirm issues with is_numeric() wrt. strings in binary notation
>>>>> in PHP 5.4.7:
>>>>>
>>>>> >>> is_numeric('0b1010')
>>>>> false
>>>>> >>> is_numeric(0b1010)
>>>>> true
>>>>
>>>> ACK. However, it is unsurprising to me that the latter would return
>>>> TRUE because there the literal is parsed into an “int” value *before*
>>>> it is passed to is_numeric(), the equivalent of is_numeric(10).
>>>>
>>>> I would rather the former bug was an implementation bug instead of a
>>>> documentation bug, because such a function should either work for all
>>>> supported numeric representations of the programming language, or there
>>>> should be a parameter specifying which representations are supported
>>>> for the specific call [like ECMAScripts parseInt(number : String, base
>>>> : Number) : Number].
>>>
>>> Thomas,
>>
>> This is NetNews, not e-mail.
>
> Um, ok. So you chastise people about using real names yet don't want
> yours used?
No, I am reminding you of the fact that I am not the only recipient of your
posting, even though your posting is a follow-up to mine.
>>> Looking into the source (PHP) there is no code to support binary
>>> strings of the type '0b1010101'. The code for hexadecimal is there
>>> however.
>>
>> AISB, testing with PHP does not help to resolve the basic issue here.
>> From such tests it is still unclear whether not supporting the binary
>> format is an implementation bug, i. e. an omission of supporting the
>> binary format introduced with PHP 5.4; or a documentation bug, i. e.
>> manual claiming that is_numeric() supports more than it is actually
>> supposed to.
>>
>> What would be interesting instead is to look at the source code from
>> which PHP 5.4 and particularly is_numeric() is built as that could at
>> least show if the octal format would be recognized, and if there was
>> support for the binary format that was just not properly triggered.
>
> Isn't that what I just mentioned I did ('Looking into the source
> code...') above?
I am not sure. Which source code have you been looking into?
> There is no support for binary numbers passed as strings in the form
> '0b101010'.
You are still missing the point. It is already clear to at least two people
here that there is no support. It is not clear why, as this format for
numeric literals was introduced only recently, and as the documentation
states something else.
> If you pass 0b101010 (not as a string) and it gets converted to an (int)
> on the way in then that's obviously not the same thing.
I am/We are aware of that.
> And what is so special about octal that is_numeric() would not recognise
> it?
It has no “8” figure.
> Who is this 'PointedEars', get a real name will you?
I sign my postings with the nickname under which I am known on the Net.
My first and last name are in the From header field value of my postings,
surrounding my nickname. Yours are not. Thus, you are not posting using
your real name, which is not considered polite on Usenet.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-17 20:39 +0200 |
| Message-ID | <kn5tgn$6j7$1@speranza.aioe.org> |
| In reply to | #9406 |
Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> Isn't that what I just mentioned I did ('Looking into the source
>> code...') above?
>
> I am not sure. Which source code have you been looking into?
In PHP 5.4 the definition of is_numeric() is in ext/standard/type.c (~
line 300ff)[1]. The relevant function to do the check for arguments of
type string is is_numeric_string_ex() in Zend/zend_operators.h (~ line
109ff)[2]. Apparently special support for strings in binary as well as
octal notation is missing; only strings in decimal and hexadecimal
notation are recognized as such (strings in octal notation are treated
as being decimal).
>> There is no support for binary numbers passed as strings in the form
>> '0b101010'.
>
> You are still missing the point. It is already clear to at least two people
> here that there is no support. It is not clear why, as this format for
> numeric literals was introduced only recently, and as the documentation
> states something else.
>
>> If you pass 0b101010 (not as a string) and it gets converted to an (int)
>> on the way in then that's obviously not the same thing.
>
> I am/We are aware of that.
>
>> And what is so special about octal that is_numeric() would not recognise
>> it?
>
> It has no “8” figure.
Nonetheless in PHP 5.3.23 as well as PHP 5.4.7:
$ php -r 'var_dump(is_numeric("08"));'
bool(true)
This is obviously caused by the missing special treatment of strings in
octal notation in is_numeric_string_ex().
[1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/type.c>
[2] <http://lxr.php.net/xref/PHP_5_4/Zend/zend_operators.h>
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-17 23:45 +0200 |
| Message-ID | <4361094.uAsmXINkQ4@PointedEars.de> |
| In reply to | #9408 |
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> Isn't that what I just mentioned I did ('Looking into the source
>>> code...') above?
>>
>> I am not sure. Which source code have you been looking into?
>
> In PHP 5.4 the definition of is_numeric() is in ext/standard/type.c (~
> line 300ff)[1]. The relevant function to do the check for arguments of
> type string is is_numeric_string_ex() in Zend/zend_operators.h (~ line
> 109ff)[2]. Apparently special support for strings in binary as well as
> octal notation is missing; only strings in decimal and hexadecimal
> notation are recognized as such (strings in octal notation are treated
> as being decimal).
>
> […] in PHP 5.3.23 as well as PHP 5.4.7:
>
> $ php -r 'var_dump(is_numeric("08"));'
> bool(true)
>
> This is obviously caused by the missing special treatment of strings in
> octal notation in is_numeric_string_ex().
>
> [1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/type.c>
> [2] <http://lxr.php.net/xref/PHP_5_4/Zend/zend_operators.h>
Thank you. Perhaps you should file a documentation bug (as you have
experience with that) in the hopes that this will be considered an
implementation bug by The PHP Group after all.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-18 14:47 +0200 |
| Message-ID | <kn7t86$jvs$1@speranza.aioe.org> |
| In reply to | #9409 |
Thomas 'PointedEars' Lahn wrote: > Thank you. Perhaps you should file a documentation bug (as you have > experience with that) in the hopes that this will be considered an > implementation bug by The PHP Group after all. I have filed the issue as Doc Bug #64877[1]. [1] <https://bugs.php.net/bug.php?id=64877> -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | SwissCheese <swisscheese@cfl.rr.com> |
|---|---|
| Date | 2013-05-15 20:57 -0400 |
| Message-ID | <kn1ame$mn8$1@dont-email.me> |
| In reply to | #9332 |
On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
> On 5/14/2013 9:43 PM, SwissCheese wrote:
>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email@address.com> wrote:
>>>
>>>> In article <kmqs3c$e3s$1@dont-email.me>, jstucklex@attglobal.net
>>>> says...
>>>>> As others have shown, is_numeric() returns false in several versions
>>>>> of PHP.
>>>>>
>>>>
>>>> I have just typed in an exact copy of the test in my message of 02:58pm
>>>> When you have run that on an apache PHP installation of the same
>>>> version
>>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>>
>>>> Otherwise I'm done repeating myself.
>>>>
>>>
>>> <?php
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>> ?>
>>>
>>> Prints 'okay'
>>>
>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>
>>
>> That's backwards... you want:
>>
>> $a = 'x11.11c';
>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>
>> Sorry, hit send too quick!
>>
>
> No, Richard had it correct. The if statement returns false, which is
> 'ok'. Your code would return 'not ok' - which is incorrect.
>
If $a ('x11.11c') is numeric then it would return 'ok' but it is not so
it returns 'not ok'. 'x11.11c' is not hexadecimal, it lacks the leading
'0' and contains a decimal/period.
php > $tests =
array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010",
"10101010101010101010101010101010101010101010101010101010101010101010101010101010101010");
php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is
numeric".PHP_EOL; } else { echo "$a is not numeric".PHP_EOL; } }
42 is numeric
1337 is numeric
0xf4c3b00c is numeric
x11.11c is not numeric
0x11.11c is not numeric
0x1111c is numeric
0b1010 is not numeric
10101010101010101010101010101010101010101010101010101010101010101010101010101010101010
is numeric
From what I can tell from the source code (of PHP) there is no code
to handle binary strings as explained in the function definition at
php.net. But I guess by definition it can only be 0's and 1's as seen
above.
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-16 00:09 -0400 |
| Message-ID | <kn1lvb$28f$1@dont-email.me> |
| In reply to | #9379 |
On 5/15/2013 8:57 PM, SwissCheese wrote:
> On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
>> On 5/14/2013 9:43 PM, SwissCheese wrote:
>>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email@address.com> wrote:
>>>>
>>>>> In article <kmqs3c$e3s$1@dont-email.me>, jstucklex@attglobal.net
>>>>> says...
>>>>>> As others have shown, is_numeric() returns false in several versions
>>>>>> of PHP.
>>>>>>
>>>>>
>>>>> I have just typed in an exact copy of the test in my message of
>>>>> 02:58pm
>>>>> When you have run that on an apache PHP installation of the same
>>>>> version
>>>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>>>
>>>>> Otherwise I'm done repeating myself.
>>>>>
>>>>
>>>> <?php
>>>> $a = 'x11.11c';
>>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>>> ?>
>>>>
>>>> Prints 'okay'
>>>>
>>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>>
>>>
>>> That's backwards... you want:
>>>
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>>
>>> Sorry, hit send too quick!
>>>
>>
>> No, Richard had it correct. The if statement returns false, which is
>> 'ok'. Your code would return 'not ok' - which is incorrect.
>>
>
> If $a ('x11.11c') is numeric then it would return 'ok' but it is not so
> it returns 'not ok'. 'x11.11c' is not hexadecimal, it lacks the leading
> '0' and contains a decimal/period.
>
'ok' is correct in this instance. is_numeric() should NOT return a
numeric value; if it did, that would be incorrect.
You are confusing 'not numeric' with 'not ok'. The first would return
whether the value is numeric or not. The second returns whether the
function returns the correct value or not.
The correct value is that the parameter is NOT a valid numeric value, so
'ok' (the function worked correctly) is the correct response.
> php > $tests =
> array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010",
> "10101010101010101010101010101010101010101010101010101010101010101010101010101010101010");
>
> php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is
> numeric".PHP_EOL; } else { echo "$a is not numeric".PHP_EOL; } }
> 42 is numeric
> 1337 is numeric
> 0xf4c3b00c is numeric
> x11.11c is not numeric
> 0x11.11c is not numeric
> 0x1111c is numeric
> 0b1010 is not numeric
> 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010
> is numeric
>
>
> From what I can tell from the source code (of PHP) there is no code
> to handle binary strings as explained in the function definition at
> php.net. But I guess by definition it can only be 0's and 1's as seen
> above.
>
>
>
Binary strings are a completely different problem introduces by the
troll 'Pointed Head' which has nothing to do with the OP's problem. But
then 'Pointed Head' is notorious (in several newsgroups) for hijacking
threads for his own purpose.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2013-05-17 01:17 +0200 |
| Message-ID | <kn3pe4$s8o$1@speranza.aioe.org> |
| In reply to | #9382 |
Jerry Stuckle wrote: > Binary strings are a completely different problem introduces by the > troll 'Pointed Head' which has nothing to do with the OP's problem. But > then 'Pointed Head' is notorious (in several newsgroups) for hijacking > threads for his own purpose. Interestingly enough, the topic of this thread is "bug in is_numeric". Apparently the only bug of is_numeric() pointed out in this rather lenghty thread is the behavior regarding numeric strings in binary notation (and maybe octal notation also). Indeed, this has nothing to do with the OP's problem, but ISTM that that was not related to is_numeric() at all. Anyway, indicating that there's a bug in is_numeric() (or its documentation) doesn't seem like "hijacking a thread for one's own purpose" to me. On the contrary, I consider it a valuable contribution. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-16 20:30 -0400 |
| Message-ID | <kn3tgd$f1s$1@dont-email.me> |
| In reply to | #9399 |
On 5/16/2013 7:17 PM, Christoph Becker wrote: > Jerry Stuckle wrote: >> Binary strings are a completely different problem introduces by the >> troll 'Pointed Head' which has nothing to do with the OP's problem. But >> then 'Pointed Head' is notorious (in several newsgroups) for hijacking >> threads for his own purpose. > > Interestingly enough, the topic of this thread is "bug in is_numeric". > Apparently the only bug of is_numeric() pointed out in this rather > lenghty thread is the behavior regarding numeric strings in binary > notation (and maybe octal notation also). > > Indeed, this has nothing to do with the OP's problem, but ISTM that that > was not related to is_numeric() at all. > > Anyway, indicating that there's a bug in is_numeric() (or its > documentation) doesn't seem like "hijacking a thread for one's own > purpose" to me. On the contrary, I consider it a valuable contribution. > No, but since it is unrelated to the OP's problem, it's nothing more than thread hijacking - something Pointed Head is well known for, as I said before. If Pointed Head wanted to bring it up, he should have started a new thread. Or, better yet, reported it on the PHP bugs database, since none of the PHP developers pay attention to this newsgroup. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web