| bug in is_numeric [message #181319] |
Sun, 12 May 2013 14:22  |
fred
Messages: 7
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
Using PHP 5.3.6 on win7-74
if(is_numeric('x11.11c') returns TRUE
and variations eg: z1111x is also true
this does not seem right to me.
I've done a search but cant find mention in buglist.
Perhaps someone more knowledgable can deal with this.
I've tried to mention elsewhere but PHP.net seems to be going
out of its way to make life impossible
|
|
|
|
| Re: bug in is_numeric [message #181320 is a reply to message #181319] |
Sun, 12 May 2013 15:31  |
Salvatore
Messages: 38
Registered: September 2012
Karma: 0
|
Member |
|
|
On 2013-05-12, fred <email(at)address(dot)com> wrote:
> Using PHP 5.3.6 on win7-74
>
> if(is_numeric('x11.11c') returns TRUE
> and variations eg: z1111x is also true
>
> this does not seem right to me.
> I've done a search but cant find mention in buglist.
>
> Perhaps someone more knowledgable can deal with this.
> I've tried to mention elsewhere but PHP.net seems to be going
> out of its way to make life impossible
>
You are correct. That parameter, when passed to is_numeric(), should
return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
Could you try the following code and let me know what comes out?
<?php $a = is_numeric('x11.11c'); var_dump($a); ?>
--
Blah blah bleh...
GCS/CM d(-)@>-- s+:- !a C++$ UBL++++$ L+$ W+++$ w M++ Y++ b++
|
|
|
|
| Re: bug in is_numeric [message #181321 is a reply to message #181320] |
Sun, 12 May 2013 15:55 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12-05-2013 17:31, Salvatore wrote:
> On 2013-05-12, fred <email(at)address(dot)com> wrote:
>> Using PHP 5.3.6 on win7-74
>>
>> if(is_numeric('x11.11c') returns TRUE
>> and variations eg: z1111x is also true
>>
>> this does not seem right to me.
>> I've done a search but cant find mention in buglist.
>>
>> Perhaps someone more knowledgable can deal with this.
>> I've tried to mention elsewhere but PHP.net seems to be going
>> out of its way to make life impossible
>>
>
> You are correct. That parameter, when passed to is_numeric(), should
> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>
> Could you try the following code and let me know what comes out?
>
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
>
>
C:\temp>ver
Microsoft Windows [Version 6.1.7601]
C:\temp>php -v
PHP 5.4.13 (cli) (built: Mar 15 2013 02:07:14)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
C:\temp>type test.php
<?php $a = is_numeric('x11.11c'); var_dump($a); ?>
C:\temp>php test.php
bool(false)
C:\temp>
|
|
|
|
| Re: bug in is_numeric [message #181322 is a reply to message #181320] |
Sun, 12 May 2013 15:58 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12-05-2013 17:31, Salvatore wrote:
> On 2013-05-12, fred <email(at)address(dot)com> wrote:
>> Using PHP 5.3.6 on win7-74
>>
>> if(is_numeric('x11.11c') returns TRUE
>> and variations eg: z1111x is also true
>>
>> this does not seem right to me.
>> I've done a search but cant find mention in buglist.
>>
>> Perhaps someone more knowledgable can deal with this.
>> I've tried to mention elsewhere but PHP.net seems to be going
>> out of its way to make life impossible
>>
>
> You are correct. That parameter, when passed to is_numeric(), should
> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>
> Could you try the following code and let me know what comes out?
>
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
>
>
luuk@opensuse:~/tmp> php test.php
bool(false)
luuk@opensuse:~/tmp>
(just to make it complete)
|
|
|
|
| Re: bug in is_numeric [message #181323 is a reply to message #181319] |
Sun, 12 May 2013 16:03 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
fred wrote:
> […]
<http://www.catb.org/esr/faqs/smart-questions.html#idp5122192>
> I've tried to mention elsewhere but PHP.net seems to be going
> out of its way to make life impossible
So you are actually trolling?
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: bug in is_numeric [message #181324 is a reply to message #181320] |
Sun, 12 May 2013 16:06 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Salvatore schrieb:
> Could you try the following code and let me know what comes out?
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
Windows XP, PHP 5.2.4 -- false
Windows XP, PHP 5.2.12 -- false
Windows XP, PHP 5.3.2 -- false
Windows XP, PHP 5.3.18 -- false
Windows XP, PHP 5.4.8 -- false
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: bug in is_numeric [message #181325 is a reply to message #181320] |
Sun, 12 May 2013 16:24 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 12 May 2013 15:31:10 +0000, Salvatore wrote:
> Could you try the following code and let me know what comes out?
>
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
$ ./test_numeric.php
string(105) "#!/usr/bin/php
<?php
var_dump( file_get_contents( __FILE__ ) );
var_dump( is_numeric( 'x11.11c' ) );
?>
"
bool(false)
$ php --version
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013
14:31:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
$ uname -r
3.2.0-41-generic
$ cat /etc/issue
Ubuntu 12.04.2 LTS \n \l
$
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: bug in is_numeric [message #181326 is a reply to message #181319] |
Sun, 12 May 2013 16:47 |
Sanders Kaufman
Messages: 24
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
"fred" wrote in message
news:MPG(dot)2bf9b5f139f7cb7d9896aa(at)news(dot)virginmedia(dot)com...
> if(is_numeric('x11.11c') returns TRUE
Try it without the quotation marks around the number.
Quotes turn a number into a string.
|
|
|
|
| Re: bug in is_numeric [message #181327 is a reply to message #181326] |
Sun, 12 May 2013 16:56 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12-05-2013 18:47, Sanders Kaufman wrote:
>
>
> "fred" wrote in message
> news:MPG(dot)2bf9b5f139f7cb7d9896aa(at)news(dot)virginmedia(dot)com...
>
>> if(is_numeric('x11.11c') returns TRUE
>
> Try it without the quotation marks around the number.
> Quotes turn a number into a string.
That wont work:
luuk@opensuse:~/tmp> cat test.php
<?php $a = is_numeric(x11.11c); var_dump($a); ?>
luuk@opensuse:~/tmp> php test.php
PHP Parse error: syntax error, unexpected T_DNUMBER in
/home/luuk/tmp/test.php on line 1
luuk@opensuse:~/tmp>
and on Windows:
Parse error: syntax error, unexpected '.11' (T_DNUMBER) in
O:\tmp\test.php on line 1
|
|
|
|
| Re: bug in is_numeric [message #181328 is a reply to message #181326] |
Sun, 12 May 2013 17:05 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Sanders Kaufman schrieb:
>> if(is_numeric('x11.11c') returns TRUE
> Try it without the quotation marks around the number.
Which number? x11.11c is not a number.
> Quotes turn a number into a string.
is_numeric() should return TRUE if the argument is a string containing
the representation of a numeric value. That's the point of this function.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
|
|
| Re: bug in is_numeric [message #181330 is a reply to message #181328] |
Sun, 12 May 2013 17:38 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Thomas Mlynarczyk wrote:
> Sanders Kaufman schrieb:
>>> if(is_numeric('x11.11c') returns TRUE
>> Try it without the quotation marks around the number.
>
> Which number? x11.11c is not a number.
The misconception might partially draw from the fact that 0x11 is a number,
the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP). In
other programming languages that require a leading “0” and do not have “.”
as (concatenation) operator,
x11.11c
could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 × 16⁻³ =
17.06958 (BTW, I have written a drop-in replacement for ECMAScript's
parseFloat() that can do that, with the usual rounding errors [1]).
In PHP, however,
x11.11c
would be equivalent to
(x11) . (11c)
which is a syntax error because constant identifiers must not start with a
decimal digit, and decimal literals must not contain a letter:
$ php -r 'echo x11 . 11c;'
PHP Parse error: syntax error, unexpected 'c' (T_STRING), expecting ',' or
';' in Command line code on line 1
$ php -r 'echo x11 . 11;'
PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command line
code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
x1111
$ php -r 'echo x11 . x11c;'
PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command line
code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
PHP Notice: Use of undefined constant x11c - assumed 'x11c' in Command line
code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
x11x11c
$ php -v
PHP 5.4.4-15 (cli) (built: Mar 22 2013 15:41:03)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v3.0.1, Copyright (c) 2005-2013, by mOo
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
with XCache Optimizer v3.0.1, Copyright (c) 2005-2013, by mOo
with XCache Cacher v3.0.1, Copyright (c) 2005-2013, by mOo
with XCache Coverager v3.0.1, Copyright (c) 2005-2013, by mOo
>> Quotes turn a number into a string.
>
> is_numeric() should return TRUE if the argument is a string containing
> the representation of a numeric value. That's the point of this function.
Not quite. It also works for non-strings as arguments. [2]
is_numeric(1) === TRUE
Thus it is better to say that is_numeric() returns TRUE if PHP's ”type
juggling” [3] (or, more formal, “implicit type conversion”), if necessary,
would allow the argument to be interpreted as a numeric value in an
arithmetic expression.
_____
[1] <http://pointedears.de/scripts/test/string>
[2] <http://php.net/is_numeric>
[3] <http://php.net/manual/en/language.types.type-juggling.php>
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
|
|
|
|
|
|
| Re: bug in is_numeric [message #181332 is a reply to message #181320] |
Sun, 12 May 2013 17:41 |
fred
Messages: 7
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
In article <kmocju$232o$1(at)yojimbo(dot)hack>, sal(at)yojimbo(dot)hack(dot)invalid
says...
> You are correct. That parameter, when passed to is_numeric(), should
> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>
> Could you try the following code and let me know what comes out?
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
Hi sal
OK I get false when I do that.
"bool(false)" to be more precise.
var_export($a)also reports false if thats any help.
|
|
|
|
| Re: bug in is_numeric [message #181333 is a reply to message #181330] |
Sun, 12 May 2013 17:46 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Thomas Mlynarczyk wrote:
>> Sanders Kaufman schrieb:
>>>> if(is_numeric('x11.11c') returns TRUE
>>> Try it without the quotation marks around the number.
>>
>> Which number? x11.11c is not a number.
>
> The misconception might partially draw from the fact that 0x11 is a
> number,
> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
> In other programming languages that require a leading “0” and do not have
^ do not
> “.” as (concatenation) operator,
>
> x11.11c
>
> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 × 16⁻³
> = 17.06958 […]
|
|
|
|
| Re: bug in is_numeric [message #181334 is a reply to message #181320] |
Sun, 12 May 2013 18:03 |
Robert Heller
Messages: 60
Registered: December 2010
Karma: 0
|
Member |
|
|
At Sun, 12 May 2013 15:31:10 +0000 (UTC) Salvatore <sal(at)yojimbo(dot)hack(dot)invalid> wrote:
>
> On 2013-05-12, fred <email(at)address(dot)com> wrote:
>> Using PHP 5.3.6 on win7-74
>>
>> if(is_numeric('x11.11c') returns TRUE
>> and variations eg: z1111x is also true
>>
>> this does not seem right to me.
>> I've done a search but cant find mention in buglist.
>>
>> Perhaps someone more knowledgable can deal with this.
>> I've tried to mention elsewhere but PHP.net seems to be going
>> out of its way to make life impossible
>>
>
> You are correct. That parameter, when passed to is_numeric(), should
> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>
> Could you try the following code and let me know what comes out?
>
> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
sauron.deepsoft.com% uname -a
Linux sauron.deepsoft.com 2.6.18-348.3.1.el5xen #1 SMP Mon Mar 11 20:28:48 EDT
2013 x86_64 x86_64 x86_64 GNU/Linux
sauron.deepsoft.com% php -v
PHP 5.2.17 (cli) (built: Apr 24 2012 15:20:19)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
sauron.deepsoft.com% cat >temp.php
<?php $a = is_numeric('x11.11c'); var_dump($a); ?>
sauron.deepsoft.com% php temp.php
bool(false)
sauron.deepsoft.com% cat /etc/redhat-release
CentOS release 5.9 (Final)
>
>
--
Robert Heller -- 978-544-6933 / heller(at)deepsoft(dot)com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
|
|
|
|
| Re: bug in is_numeric [message #181335 is a reply to message #181330] |
Sun, 12 May 2013 18:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
> Thomas Mlynarczyk wrote:
>
>> Sanders Kaufman schrieb:
>>>> if(is_numeric('x11.11c') returns TRUE
>>> Try it without the quotation marks around the number.
>>
>> Which number? x11.11c is not a number.
>
> The misconception might partially draw from the fact that 0x11 is a number,
> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP). In
> other programming languages that require a leading “0” and do not have “.”
> as (concatenation) operator,
>
> x11.11c
>
> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 × 16⁻³ =
> 17.06958 (BTW, I have written a drop-in replacement for ECMAScript's
> parseFloat() that can do that, with the usual rounding errors [1]).
>
> In PHP, however,
>
> x11.11c
>
> would be equivalent to
>
> (x11) . (11c)
>
Wrong, as usual.
<snip>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181336 is a reply to message #181335] |
Sun, 12 May 2013 18:39 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>> Thomas Mlynarczyk wrote:
>>> Sanders Kaufman schrieb:
>>>> > if(is_numeric('x11.11c') returns TRUE
>>>> Try it without the quotation marks around the number.
>>>
>>> Which number? x11.11c is not a number.
>>
>> The misconception might partially draw from the fact that 0x11 is a
>> number,
>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>> In other programming languages that require a leading “0” and do not have
>> “.” as (concatenation) operator,
>>
>> x11.11c
>>
>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>> ECMAScript's parseFloat() that can do that, with the usual rounding
>> errors [1]).
>>
>> In PHP, however,
>>
>> x11.11c
>>
>> would be equivalent to
>>
>> (x11) . (11c)
>>
>
> Wrong, as usual.
>
> <snip>
Intentionally misquoted, as usual.
F'up2 where it belongs
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
|
|
|
|
|
|
| Re: bug in is_numeric [message #181338 is a reply to message #181336] |
Sun, 12 May 2013 20:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>> Thomas Mlynarczyk wrote:
>>>> Sanders Kaufman schrieb:
>>>> >> if(is_numeric('x11.11c') returns TRUE
>>>> > Try it without the quotation marks around the number.
>>>>
>>>> Which number? x11.11c is not a number.
>>>
>>> The misconception might partially draw from the fact that 0x11 is a
>>> number,
>>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>> In other programming languages that require a leading “0” and do not have
>>> “.” as (concatenation) operator,
>>>
>>> x11.11c
>>>
>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>> errors [1]).
>>>
>>> In PHP, however,
>>>
>>> x11.11c
>>>
>>> would be equivalent to
>>>
>>> (x11) . (11c)
>>>
>>
>> Wrong, as usual.
>>
>> <snip>
>
> Intentionally misquoted, as usual.
>
>
> F'up2 where it belongs
>
> PointedEars
>
And exactly what is wrong with what I quoted? The rest of your trash
was based on this incorrect premise; it would be a waste of bandwidth to
repost your entire tripe.
But then I guess you like to ride "my.little.pony", which is why you set
the FUP. You can't handle someone correcting your errors. Probably
because you are so seldom correct about anything.
Why don't you get a job where you can understand what's going on?
Hamburger flipper comes to mind...
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181339 is a reply to message #181338] |
Sun, 12 May 2013 23:27 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Thomas Mlynarczyk wrote:
>>>> > Sanders Kaufman schrieb:
>>>> >>> if(is_numeric('x11.11c') returns TRUE
>>>> >> Try it without the quotation marks around the number.
>>>> >
>>>> > Which number? x11.11c is not a number.
>>>>
>>>> The misconception might partially draw from the fact that 0x11 is a
>>>> number,
>>>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>>> In other programming languages that require a leading “0” and do not
>>>> have “.” as (concatenation) operator,
>>>>
>>>> x11.11c
>>>>
>>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> errors [1]).
>>>>
>>>> In PHP, however,
>>>>
>>>> x11.11c
>>>>
>>>> would be equivalent to
>>>>
>>>> (x11) . (11c)
>>>>
>>>
>>> Wrong, as usual.
>>>
>>> <snip>
>>
>> Intentionally misquoted, as usual.
>
> And exactly what is wrong with what I quoted?
In contrast to what you stated, exactly *nothing* is wrong with it when
properly quoted; that is, *in context*, which is the point. Giving you the
benefit of a doubt, you appear to have severe difficulty understanding the
concept of context as such and the importance of context in quotations
specifically; it would be good if you could work on that.
> The rest of your trash
Not everything that you choose to ignore or fail to understand is “trash”
because of that.
> was based on this incorrect premise; it would be a waste of bandwidth to
> repost your entire tripe.
As showed by the PHP output that I posted further below, and that you
snipped, the premise is _not_ incorrect. To elaborate:
“.” would be considered a concatenation operator here; there is no other
production of the PHP grammar that fits the source code better. Numeric
literals must not start with “x” in PHP, which precludes the possibility
that “.” would be parsed as a decimal point of the literal “x11.11” (which,
giving you the benefit of a doubt, might have been your assumption drawing
from other programming languages that you might know).
As a result, “x11“ would be considered a constant's identifier; because such
a constant would likele be undeclared, it would be parsed as if it was a
string value containing the characters of the would-be identifier as
characters (see the PHP Notices in the test, and the generated output for
proof of that).
“11c” would be considered a constant identifier as well (and treated the
same way) if it did not start with a decimal digit. Or it would be
considered a decimal literal if it did not contain/end with “c” (allowed
would only be “e” followed by a decimal literal, for the
exponential/scientific decimal format). But as it does contain/end with “c”
that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
the entire expression would not compile and the entire PHP program would not
compile, being syntactically in error.
We have now ascertained that, as Thomas Mlynarczyk stated, “x11.11c” cannot
be a proper numeric literal in PHP (it would be an operation expression
[that would not compile, but that is unimportant from here]). As that is
the case, “'x11.11c'” also is not considered numeric in PHP, which is why
is_numeric('x11.11c')
must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
However, there appears to be an *actual* mismatch between PHP manual and
implementation in said PHP version as
is_numeric('0b11001001')
returns FALSE when according to the manual it should return TRUE (binary
integer literals are available since PHP 5.4.0 per the manual, and they do
compile and properly evaluate in tests there.
> [more flames]
It is a pity that too often you are not able to master your emotions in
order to participate in a factual discussion in a constructive way.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: bug in is_numeric [message #181340 is a reply to message #181339] |
Mon, 13 May 2013 00:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Thomas Mlynarczyk wrote:
>>>> >> Sanders Kaufman schrieb:
>>>> >>>> if(is_numeric('x11.11c') returns TRUE
>>>> >>> Try it without the quotation marks around the number.
>>>> >>
>>>> >> Which number? x11.11c is not a number.
>>>> >
>>>> > The misconception might partially draw from the fact that 0x11 is a
>>>> > number,
>>>> > the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>>> > In other programming languages that require a leading “0” and do not
>>>> > have “.” as (concatenation) operator,
>>>> >
>>>> > x11.11c
>>>> >
>>>> > could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> > 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> > ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> > errors [1]).
>>>> >
>>>> > In PHP, however,
>>>> >
>>>> > x11.11c
>>>> >
>>>> > would be equivalent to
>>>> >
>>>> > (x11) . (11c)
>>>> >
>>>>
>>>> Wrong, as usual.
>>>>
>>>> <snip>
>>>
>>> Intentionally misquoted, as usual.
>>
>> And exactly what is wrong with what I quoted?
>
> In contrast to what you stated, exactly *nothing* is wrong with it when
> properly quoted; that is, *in context*, which is the point. Giving you the
> benefit of a doubt, you appear to have severe difficulty understanding the
> concept of context as such and the importance of context in quotations
> specifically; it would be good if you could work on that.
>
That was the beginning of your reply. There was no previous context to
quote.
>> The rest of your trash
>
> Not everything that you choose to ignore or fail to understand is “trash”
> because of that.
>
No, but almost *everything* you say is pure tripe. You can't blame this
on the "context".
>> was based on this incorrect premise; it would be a waste of bandwidth to
>> repost your entire tripe.
>
> As showed by the PHP output that I posted further below, and that you
> snipped, the premise is _not_ incorrect. To elaborate:
>
The premise is completely incorrect. 'x11.11c' is NEVER considered a
numeric value, as several other people (including me) have shown. And
the '.' is NEVER an operator when within a quoted string.
> “.” would be considered a concatenation operator here; there is no other
> production of the PHP grammar that fits the source code better. Numeric
> literals must not start with “x” in PHP, which precludes the possibility
> that “.” would be parsed as a decimal point of the literal “x11.11” (which,
> giving you the benefit of a doubt, might have been your assumption drawing
> from other programming languages that you might know).
>
Nope. Not when it is within a quoted string.
> As a result, “x11“ would be considered a constant's identifier; because such
> a constant would likele be undeclared, it would be parsed as if it was a
> string value containing the characters of the would-be identifier as
> characters (see the PHP Notices in the test, and the generated output for
> proof of that).
>
Nope, not unless there was a define ('x11',...) statement previous to
this. It is a string - plain and simple. But you don't understand such
a simple concept.
> “11c” would be considered a constant identifier as well (and treated the
> same way) if it did not start with a decimal digit. Or it would be
> considered a decimal literal if it did not contain/end with “c” (allowed
> would only be “e” followed by a decimal literal, for the
> exponential/scientific decimal format). But as it does contain/end with “c”
> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
> the entire expression would not compile and the entire PHP program would not
> compile, being syntactically in error.
>
Wrong again. In PHP you have to have a define() statement to create a
constant. It is part of string. However, that's way beyond your
comprehension.
> We have now ascertained that, as Thomas Mlynarczyk stated, “x11.11c” cannot
> be a proper numeric literal in PHP (it would be an operation expression
> [that would not compile, but that is unimportant from here]). As that is
> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>
No, it is a string value, nothing more, nothing less.
> is_numeric('x11.11c')
>
> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>
is_numeric('0x11') has nothing to do with the problem at hand.
> However, there appears to be an *actual* mismatch between PHP manual and
> implementation in said PHP version as
>
> is_numeric('0b11001001')
>
> returns FALSE when according to the manual it should return TRUE (binary
> integer literals are available since PHP 5.4.0 per the manual, and they do
> compile and properly evaluate in tests there.
>
Again, absolutely nothing to do with this problem.
>> [more flames]
>
> It is a pity that too often you are not able to master your emotions in
> order to participate in a factual discussion in a constructive way.
>
>
> PointedEars
>
It's a pity you are so stoopid that you can't understand even simple
concepts so as to be able to participate in an intelligent discussion.
I suggest you try washing dishes. It's more your speed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181341 is a reply to message #181340] |
Mon, 13 May 2013 09:07 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >> Thomas Mlynarczyk wrote:
>>>> >>> Sanders Kaufman schrieb:
>>>> >>>>> if(is_numeric('x11.11c') returns TRUE
>>>> >>>> Try it without the quotation marks around the number.
>>>> >>>
>>>> >>> Which number? x11.11c is not a number.
>>>> >>
>>>> >> The misconception might partially draw from the fact that 0x11 is a
>>>> >> number, the hexadecimal representation of decimal 16¹ + 16⁰ = 17
>>>> >> (even in PHP).
To be clear, I was referring to *Sanders'* misconception.
>>>> >> In other programming languages that require a leading
>>>> >> “0” and do not have “.” as (concatenation) operator,
>>>> >>
>>>> >> x11.11c
>>>> >>
>>>> >> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> >> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> >> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> >> errors [1]).
>>>> >>
>>>> >> In PHP, however,
>>>> >>
>>>> >> x11.11c
>>>> >>
>>>> >> would be equivalent to
>>>> >>
>>>> >> (x11) . (11c)
>>>> >>
>>>> >
>>>> > Wrong, as usual.
>>>> >
>>>> > <snip>
>>>>
>>>> Intentionally misquoted, as usual.
>>>
>>> And exactly what is wrong with what I quoted?
>>
>> In contrast to what you stated, exactly *nothing* is wrong with it when
>> properly quoted; that is, *in context*, which is the point. Giving you
>> the benefit of a doubt, you appear to have severe difficulty
>> understanding the concept of context as such and the importance of
>> context in quotations specifically; it would be good if you could work on
>> that.
>
> That was the beginning of your reply. There was no previous context to
> quote.
It was the text that *followed*, and that you snipped, that put the part of
my statement that you quoted, in context.
>>> The rest of your trash
>>
>> Not everything that you choose to ignore or fail to understand is “trash”
>> because of that.
>
> No, but almost *everything* you say is pure tripe. You can't blame this
> on the "context".
You proceed from the false assumption that if someone is wrong on one thing
(and to date we have only *your* *opinion* on that) must be wrong on
another.
>>> was based on this incorrect premise; it would be a waste of bandwidth to
>>> repost your entire tripe.
>> As showed by the PHP output that I posted further below, and that you
>> snipped, the premise is _not_ incorrect. To elaborate:
>
> The premise is completely incorrect. 'x11.11c' is NEVER considered a
> numeric value, as several other people (including me) have shown. And
> the '.' is NEVER an operator when within a quoted string.
Apparently you do not understand that is_numeric() treats both numeric
literals and numeric representations in string literals the same. Therefore
it matters to the return value of is_numeric() if string content could be a
numeric literal when used verbatim in PHP code. I have showed that and why
it could not be a numeric literal, providing the rationale for the return
value of is_numeric().
>> As a result, “x11“ would be considered a constant's identifier; because
>> such a constant would likele be undeclared, it would be parsed as if it
>> was a string value containing the characters of the would-be identifier
>> as characters (see the PHP Notices in the test, and the generated output
>> for proof of that).
>
> Nope, not unless there was a define ('x11',...) statement previous to
> this. It is a string - plain and simple. […]
The PHP output that I posted shows that a standalone identifier – such *as
if* that string *content* was used in PHP code is met with a PHP Notice and
is *treated as* I described above from then on. The Notice is issued then
because the source code is ambiguous, therefore error-prone. As you
confirmed, if a constant having that sequence of identifiers would be
declared, the source code would change meaning.
This is important because if a sequence of characters is potentially a
constant identifier, it cannot be a numeric literal at the same time.
>> “11c” would be considered a constant identifier as well (and treated the
>> same way) if it did not start with a decimal digit. Or it would be
>> considered a decimal literal if it did not contain/end with “c” (allowed
>> would only be “e” followed by a decimal literal, for the
>> exponential/scientific decimal format). But as it does contain/end with
>> “c”
>> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
>> the entire expression would not compile and the entire PHP program would
>> not compile, being syntactically in error.
>
> Wrong again. In PHP you have to have a define() statement to create a
> constant. It is part of string. […]
I am aware that one needs define() for constants. This has nothing to do
with the fact that an identifier is treated as a string value containing the
identifiers characters if there is no constant declared with that
identifier. And it has nothing to do with the fact that a constant cannot
start with a decimal digit, or that a decimal literal cannot contain the
character “c”. That therefore such a PHP program would be syntactical in
error; that therefore, too, “x11.11c” cannot be a numeric literal, and that
therefore, too, is_numeric('x11.11c') MUST return FALSE (which, contrary to
the OP's claims, it does).
>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>> cannot be a proper numeric literal in PHP (it would be an operation
>> expression
>> [that would not compile, but that is unimportant from here]). As that is
>> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>
> No, it is a string value, nothing more, nothing less.
It is a string value whose suitability to serve as a numeric value is being
tested with is_numeric(). Therefore it matters what the PHP grammar has to
say about numeric values.
>> is_numeric('x11.11c')
>>
>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>
> is_numeric('0x11') has nothing to do with the problem at hand.
Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix make
“0x11” a proper numeric (hexadecimal integer) representation as per the PHP
grammar. Which is what is_numeric() is supposed to test.
>> However, there appears to be an *actual* mismatch between PHP manual and
>> implementation in said PHP version as
>>
>> is_numeric('0b11001001')
>>
>> returns FALSE when according to the manual it should return TRUE (binary
>> integer literals are available since PHP 5.4.0 per the manual, and they
>> do compile and properly evaluate in tests there.
>
> Again, absolutely nothing to do with this problem.
Yes, it has. The OP claimed there was a bug in is_numeric(). If we assume
the manual to be correct, this example shows that there actually *would be*
a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on Debian GNU/Linux).
But it would be *another* bug.
That might be immaterial to you, but I consider it important for my fellow
PHP developers to learn of it.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: bug in is_numeric [message #181343 is a reply to message #181332] |
Mon, 13 May 2013 11:50 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2013 7:41 PM, fred wrote:
> In article <kmocju$232o$1(at)yojimbo(dot)hack>, sal(at)yojimbo(dot)hack(dot)invalid
> says...
>> You are correct. That parameter, when passed to is_numeric(), should
>> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>>
>> Could you try the following code and let me know what comes out?
>> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
>
> Hi sal
>
> OK I get false when I do that.
> "bool(false)" to be more precise.
> var_export($a)also reports false if thats any help.
>
>
Hi Fred,
So on your current set-up is_numeric() seems to work fine.
It returns false, as expected.
But you claimed in your original post, the test returned true.
I am confused now. :-)
Could you give us the (relevant) code that made you make your first claim?
I expect it does something else than you think it does.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: bug in is_numeric [message #181347 is a reply to message #181341] |
Mon, 13 May 2013 13:02 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Jerry Stuckle wrote:
>>>> >> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >>> Thomas Mlynarczyk wrote:
>>>> >>>> Sanders Kaufman schrieb:
>>>> >>>>>> if(is_numeric('x11.11c') returns TRUE
>>>> >>>>> Try it without the quotation marks around the number.
>>>> >>>>
>>>> >>>> Which number? x11.11c is not a number.
>>>> >>>
>>>> >>> The misconception might partially draw from the fact that 0x11 is a
>>>> >>> number, the hexadecimal representation of decimal 16¹ + 16⁰ = 17
>>>> >>> (even in PHP).
>
> To be clear, I was referring to *Sanders'* misconception.
>
>>>> >>> In other programming languages that require a leading
>>>> >>> “0” and do not have “.” as (concatenation) operator,
>>>> >>>
>>>> >>> x11.11c
>>>> >>>
>>>> >>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> >>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> >>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> >>> errors [1]).
>>>> >>>
>>>> >>> In PHP, however,
>>>> >>>
>>>> >>> x11.11c
>>>> >>>
>>>> >>> would be equivalent to
>>>> >>>
>>>> >>> (x11) . (11c)
>>>> >>>
>>>> >>
>>>> >> Wrong, as usual.
>>>> >>
>>>> >> <snip>
>>>> >
>>>> > Intentionally misquoted, as usual.
>>>>
>>>> And exactly what is wrong with what I quoted?
>>>
>>> In contrast to what you stated, exactly *nothing* is wrong with it when
>>> properly quoted; that is, *in context*, which is the point. Giving you
>>> the benefit of a doubt, you appear to have severe difficulty
>>> understanding the concept of context as such and the importance of
>>> context in quotations specifically; it would be good if you could work on
>>> that.
>>
>> That was the beginning of your reply. There was no previous context to
>> quote.
>
> It was the text that *followed*, and that you snipped, that put the part of
> my statement that you quoted, in context.
>
The statement was wrong in ANY context. But you're too stoopid to
understand that. And by trying to defend your stoopidiy, you're just
making yourself seem even more stoopid.
You would have been much better off just admitting your statement was
wrong and moving on. But your ego doesn't allow that.
>>>> The rest of your trash
>>>
>>> Not everything that you choose to ignore or fail to understand is “trash”
>>> because of that.
>>
>> No, but almost *everything* you say is pure tripe. You can't blame this
>> on the "context".
>
> You proceed from the false assumption that if someone is wrong on one thing
> (and to date we have only *your* *opinion* on that) must be wrong on
> another.
>
Nope. The rest of your argument was based on a false premise.
>>>> was based on this incorrect premise; it would be a waste of bandwidth to
>>>> repost your entire tripe.
>>> As showed by the PHP output that I posted further below, and that you
>>> snipped, the premise is _not_ incorrect. To elaborate:
>>
>> The premise is completely incorrect. 'x11.11c' is NEVER considered a
>> numeric value, as several other people (including me) have shown. And
>> the '.' is NEVER an operator when within a quoted string.
>
> Apparently you do not understand that is_numeric() treats both numeric
> literals and numeric representations in string literals the same. Therefore
> it matters to the return value of is_numeric() if string content could be a
> numeric literal when used verbatim in PHP code. I have showed that and why
> it could not be a numeric literal, providing the rationale for the return
> value of is_numeric().
>
Unlike you, I understand EXACTLY what is_numeric() does. And I also
understand that 'x11' can NOT be a hexadecimal representation in PHP,
and a '.' within a quoted string is NEVER a concatenation character.
Neither of which do YOU understand.
>>> As a result, “x11“ would be considered a constant's identifier; because
>>> such a constant would likele be undeclared, it would be parsed as if it
>>> was a string value containing the characters of the would-be identifier
>>> as characters (see the PHP Notices in the test, and the generated output
>>> for proof of that).
>>
>> Nope, not unless there was a define ('x11',...) statement previous to
>> this. It is a string - plain and simple. […]
>
> The PHP output that I posted shows that a standalone identifier – such *as
> if* that string *content* was used in PHP code is met with a PHP Notice and
> is *treated as* I described above from then on. The Notice is issued then
> because the source code is ambiguous, therefore error-prone. As you
> confirmed, if a constant having that sequence of identifiers would be
> declared, the source code would change meaning.
>
Nope, it is NOT a standalone identifier, and it is NOT a constant. Once
again you show your stoopidity.
Also, the source code was NOT ambiguous. And defining a constant would
NOT change the meaning; but then once again you have no idea what you're
talking about.
> This is important because if a sequence of characters is potentially a
> constant identifier, it cannot be a numeric literal at the same time.
>
Nope, a constant identifier is NOT replaced within a quoted string.
You're just digging yourself deeper, Pointed Head.
>>> “11c” would be considered a constant identifier as well (and treated the
>>> same way) if it did not start with a decimal digit. Or it would be
>>> considered a decimal literal if it did not contain/end with “c” (allowed
>>> would only be “e” followed by a decimal literal, for the
>>> exponential/scientific decimal format). But as it does contain/end with
>>> “c”
>>> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
>>> the entire expression would not compile and the entire PHP program would
>>> not compile, being syntactically in error.
>>
>> Wrong again. In PHP you have to have a define() statement to create a
>> constant. It is part of string. […]
>
> I am aware that one needs define() for constants. This has nothing to do
> with the fact that an identifier is treated as a string value containing the
> identifiers characters if there is no constant declared with that
> identifier. And it has nothing to do with the fact that a constant cannot
> start with a decimal digit, or that a decimal literal cannot contain the
> character “c”. That therefore such a PHP program would be syntactical in
> error; that therefore, too, “x11.11c” cannot be a numeric literal, and that
> therefore, too, is_numeric('x11.11c') MUST return FALSE (which, contrary to
> the OP's claims, it does).
>
Obviously this is something new to you or you wouldn't have made that
previous statements. Nice try of backtracking, but it doesn't work.
>>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>>> cannot be a proper numeric literal in PHP (it would be an operation
>>> expression
>>> [that would not compile, but that is unimportant from here]). As that is
>>> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>>
>> No, it is a string value, nothing more, nothing less.
>
> It is a string value whose suitability to serve as a numeric value is being
> tested with is_numeric(). Therefore it matters what the PHP grammar has to
> say about numeric values.
>
It is not a constant like you indicate. Nice try of backtracking again.
>>> is_numeric('x11.11c')
>>>
>>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>>
>> is_numeric('0x11') has nothing to do with the problem at hand.
>
> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix make
> “0x11” a proper numeric (hexadecimal integer) representation as per the PHP
> grammar. Which is what is_numeric() is supposed to test.
>
Nope, that was not part of the question the OP asked; it is a spurious
and unrelated item.
>>> However, there appears to be an *actual* mismatch between PHP manual and
>>> implementation in said PHP version as
>>>
>>> is_numeric('0b11001001')
>>>
>>> returns FALSE when according to the manual it should return TRUE (binary
>>> integer literals are available since PHP 5.4.0 per the manual, and they
>>> do compile and properly evaluate in tests there.
>>
>> Again, absolutely nothing to do with this problem.
>
> Yes, it has. The OP claimed there was a bug in is_numeric(). If we assume
> the manual to be correct, this example shows that there actually *would be*
> a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on Debian GNU/Linux).
> But it would be *another* bug.
>
> That might be immaterial to you, but I consider it important for my fellow
> PHP developers to learn of it.
>
>
> PointedEars
>
Again, completely unrelated to what the OP asked. But you seem to show
your (lack of) intelligence by constantly bringing up completely
unrelated items, therefore complicating the matter unnecessarily. What
what's even funnier is when you show your stoopidity by being wrong in
so many of your claims.
Yes, you definitely have a "Pointed Head". No wonder you're so well
known as a troll in so many newsgroups.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181350 is a reply to message #181343] |
Mon, 13 May 2013 13:58 |
fred
Messages: 7
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
In article <5190d3a0$0$15991$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
erwinmollerusenet(at)xs4all(dot)nl says...
> So on your current set-up is_numeric() seems to work fine.
> It returns false, as expected.
>
No.
is_numeric() returns true.
It was var_dump() that reurned false.
> But you claimed in your original post, the test returned true.
> I am confused now. :-)
Yes you are confused.
> Could you give us the (relevant) code that made you make your first >
> claim?
$a = 'x11.11c';
if(is_numeric($a)) { echo('oops - a problem' . '<BR>') } ;
> I expect it does something else than you think it does.
What it does is something that I didn't think right - as stated.
|
|
|
|
| Re: bug in is_numeric [message #181351 is a reply to message #181350] |
Mon, 13 May 2013 14:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2013 9:58 AM, fred wrote:
> In article <5190d3a0$0$15991$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
> erwinmollerusenet(at)xs4all(dot)nl says...
>> So on your current set-up is_numeric() seems to work fine.
>> It returns false, as expected.
>>
>
> No.
> is_numeric() returns true.
> It was var_dump() that reurned false.
>
As others have shown, is_numeric() returns false in several versions of PHP.
>> But you claimed in your original post, the test returned true.
>> I am confused now. :-)
>
> Yes you are confused.
>
>> Could you give us the (relevant) code that made you make your first >
>> claim?
>
> $a = 'x11.11c';
> if(is_numeric($a)) { echo('oops - a problem' . '<BR>') } ;
>
>> I expect it does something else than you think it does.
>
> What it does is something that I didn't think right - as stated.
>
Is that cut and paste of your actual code? Is it your entire code?
What happens with the following code:
echo is_numeric('x11.11c') ? 'true' : 'false';
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181352 is a reply to message #181351] |
Mon, 13 May 2013 14:15 |
fred
Messages: 7
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)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.
|
|
|
|
| Re: bug in is_numeric [message #181353 is a reply to message #181347] |
Mon, 13 May 2013 14:57 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>>> In contrast to what you stated, exactly *nothing* is wrong with it when
>>>> properly quoted; that is, *in context*, which is the point. Giving you
>>>> the benefit of a doubt, you appear to have severe difficulty
>>>> understanding the concept of context as such and the importance of
>>>> context in quotations specifically; it would be good if you could work
>>>> on that.
>>>
>>> That was the beginning of your reply. There was no previous context to
>>> quote.
>>
>> It was the text that *followed*, and that you snipped, that put the part
>> of my statement that you quoted, in context.
>
> The statement was wrong in ANY context. […]
No, it was and is not.
> You would have been much better off just admitting your statement was
> wrong and moving on. But your ego doesn't allow that.
It has nothing to do with ego to explain to you why you misinterpret my
statement. It has to do with being honest, a concept that you appear to
have problems with.
>>>> > The rest of your trash
>>>> Not everything that you choose to ignore or fail to understand is
>>>> “trash” because of that.
>>> No, but almost *everything* you say is pure tripe. You can't blame this
>>> on the "context".
>>
>> You proceed from the false assumption that if someone is wrong on one
>> thing (and to date we have only *your* *opinion* on that) must be wrong
>> on another.
>
> Nope. The rest of your argument was based on a false premise.
It was not. Your turn.
>>>> > was based on this incorrect premise; it would be a waste of bandwidth
>>>> > to repost your entire tripe.
>>>> As showed by the PHP output that I posted further below, and that you
>>>> snipped, the premise is _not_ incorrect. To elaborate:
>>>
>>> The premise is completely incorrect. 'x11.11c' is NEVER considered a
>>> numeric value, as several other people (including me) have shown. And
>>> the '.' is NEVER an operator when within a quoted string.
>>
>> Apparently you do not understand that is_numeric() treats both numeric
>> literals and numeric representations in string literals the same.
>> Therefore it matters to the return value of is_numeric() if string
>> content could be a
>> numeric literal when used verbatim in PHP code. I have showed that and
>> why it could not be a numeric literal, providing the rationale for the
>> return value of is_numeric().
>
> Unlike you, I understand EXACTLY what is_numeric() does.
How did you get the idea that I would not understand what it does? I have
explained in great detail what it does. Your problem is that you
continuously misinterpret my statements. You should read them more
carefully.
> And I also understand that 'x11' can NOT be a hexadecimal representation
> in PHP,
Which I have already said *thrice* now.
> and a '.' within a quoted string is NEVER a concatenation character.
I am well aware of that, too. However, you are not aware that I was not
debating that fact, or claiming the opposite. I was discussing the reasons
why the argument to is_numeric() is not – cannot be – considered numeric.
>>>> As a result, “x11“ would be considered a constant's identifier; because
>>>> such a constant would likele be undeclared, it would be parsed as if it
>>>> was a string value containing the characters of the would-be identifier
>>>> as characters (see the PHP Notices in the test, and the generated
>>>> output for proof of that).
>>>
>>> Nope, not unless there was a define ('x11',...) statement previous to
>>> this. It is a string - plain and simple. […]
>>
>> The PHP output that I posted shows that a standalone identifier – such
>> *as if* that string *content* was used in PHP code is met with a PHP
>> Notice and is *treated as* I described above from then on. The Notice is
>> issued then because the source code is ambiguous, therefore error-prone.
>> As you confirmed, if a constant having that sequence of identifiers would
>> be declared, the source code would change meaning.
>
> Nope, it is NOT a standalone identifier, and it is NOT a constant. […]
Apparently you have a problem understanding the concept of a hypothetical
argument as well. I was explaining how the string *content* *would be*
parsed *if* it *would be* used verbatim in PHP code, which explains *why* it
cannot be considered numeric.
> Also, the source code was NOT ambiguous.
Again, the string *content* *would be* ambiguous *if* used *verbatim* in PHP
code, in particular the identifier *would* *make* the resulting source code
ambiguous (*assuming* it compiled).
> And defining a constant would NOT change the meaning; […]
Yes, it would. _Declaring_ a constant with the identifier
x11
would change the evaluation value of the *standalone* expression
x11
to the string representation of the value of the constant with that
identifier, instead of the string value created from the identifier's
characters. For example:
$ php -r 'echo x11 . "\n";'
PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command line
code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
x11
$ php -r 'define("x11", 42); echo x11 . "\n";'
42
Do you see the “assumed 'x11'” in the Notice?
>> This is important because if a sequence of characters is potentially a
>> constant identifier, it cannot be a numeric literal at the same time.
>
> Nope, a constant identifier is NOT replaced within a quoted string.
I said “*potentially* a constant identifier”. That is (AISB), *if* such a
constant would *not* be declared, it *would be* replaced as I described.
The PHP output I already posted *clearly* shows that. Here it is again:
| $ php -r 'echo x11 . x11c;'
| PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command
| line code on line 1
| PHP Stack trace:
| PHP 1. {main}() Command line code:0
| PHP Notice: Use of undefined constant x11c - assumed 'x11c' in Command
| line code on line 1
| PHP Stack trace:
| PHP 1. {main}() Command line code:0
| x11x11c
^^^^^^^
| $ php -v
| PHP 5.4.4-15 (cli) (built: Mar 22 2013 15:41:03)
| Copyright (c) 1997-2012 The PHP Group
| Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
| with XCache v3.0.1, Copyright (c) 2005-2013, by mOo
| with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
| with XCache Optimizer v3.0.1, Copyright (c) 2005-2013, by mOo
| with XCache Cacher v3.0.1, Copyright (c) 2005-2013, by mOo
| with XCache Coverager v3.0.1, Copyright (c) 2005-2013, by mOo
How can you deny that the concatenation
x11 . x11c
is evaluated to
'x11' . 'x11c'
and thus to
'x11x11c'
when neither identifier is that of a constant?
>>>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>>>> cannot be a proper numeric literal in PHP (it would be an operation
>>>> expression
>>>> [that would not compile, but that is unimportant from here]). As that
>>>> [is
>>>> the case, “'x11.11c'” also is not considered numeric in PHP, which is
>>>> why
>>>
>>> No, it is a string value, nothing more, nothing less.
>>
>> It is a string value whose suitability to serve as a numeric value is
>> being
>> tested with is_numeric(). Therefore it matters what the PHP grammar has
>> to say about numeric values.
>
> It is not a constant like you indicate.
I have not indicated that it is a constant. I have said repeatedly now that
*if* the string value *was* used verbatim in PHP code, it *would be*
considered a concatenation operation with the first argument being
considered a constant identifier. An identifier that *would be* resolved as
I said if *no* such constant *would be* declared.
>>>> However, there appears to be an *actual* mismatch between PHP manual
>>>> and implementation in said PHP version as
>>>>
>>>> is_numeric('0b11001001')
>>>>
>>>> returns FALSE when according to the manual it should return TRUE
>>>> (binary integer literals are available since PHP 5.4.0 per the manual,
>>>> and they do compile and properly evaluate in tests there.
>>> Again, absolutely nothing to do with this problem.
>> Yes, it has. The OP claimed there was a bug in is_numeric(). If we
>> assume the manual to be correct, this example shows that there actually
>> *would be* a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on
>> Debian GNU/Linux). But it would be *another* bug.
>>
>> That might be immaterial to you, but I consider it important for my
>> fellow PHP developers to learn of it.
>
> Again, completely unrelated to what the OP asked. […]
A difference between the documentation and the implementation of
is_numeric() is _not_ at all unrelated to the subject of “bug in
is_numeric”.
> […]
> No wonder you're so well known as a troll in so many newsgroups.
It takes one to know one.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
| Re: bug in is_numeric [message #181354 is a reply to message #181353] |
Mon, 13 May 2013 15:10 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
In order not to be misunderstood again …
Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>> On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
>>> The PHP output that I posted shows that a standalone identifier – such
>>>> > We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>>>> > cannot be a proper numeric literal in PHP (it would be an operation
>>>> > expression
>>>> > [that would not compile, but that is unimportant from here]). As that
>>>> > [is the case, “'x11.11c'” also is not considered numeric in PHP, which
>>>> > is why
>>>> No, it is a string value, nothing more, nothing less.
>>> It is a string value whose suitability to serve as a numeric value is
>>> being tested with is_numeric(). Therefore it matters what the PHP
>>> grammar has to say about numeric values.
>> It is not a constant like you indicate.
>
> I have not indicated that it is a constant. I have said repeatedly now
> that *if* the string value *was* used verbatim in PHP code, it *would be*
string _content_ (“string value” might be ambiguous)
> considered a concatenation operation with the first argument being
first _operand_, not first argument
> considered a constant identifier. An identifier that *would be* resolved
> as I said if *no* such constant *would be* declared.
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(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: bug in is_numeric [message #181357 is a reply to message #181352] |
Mon, 13 May 2013 15:29 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2013 4:15 PM, fred wrote:
> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)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.
>
>
Dear Fred,
The problem is this: You claim that your tests return true AND false.
That is why I am confused, and propably most readers in here.
You claim (in your original posting) that
if(is_numeric('x11.11c'))
returns TRUE
And you also claim that the test Salvatore suggested returns false:
<?php $a = is_numeric('x11.11c'); var_dump($a); ?>
That results in false, you posted.
Do you see the problem?
Same string ('x11.11c'), same function is_numeric, but different results.
So no need to repeat yourself, but at least take the time to look into
this problem.
I bet your code tests something else than you think it tests.
For example a row from a query, which you misinterpret, or a false
result that you juggle into a number, etc.etc.
eg: Some db-problem -> row is false -> you juggle false into 0, and test
if 0 is numeric.
There are many common mistakes possible, and some people in here can
spot them right away (because they made the same mistakes themself earlier).
Hence the question if you can post more ACTUAL code.
You showed yourself that the function is_numeric WORKS on your system by
posting the result of Salvatore's test.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: bug in is_numeric [message #181358 is a reply to message #181350] |
Mon, 13 May 2013 15:35 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 5/13/13 6:58 AM, fred wrote:
> In article <5190d3a0$0$15991$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
> erwinmollerusenet(at)xs4all(dot)nl says...
>> So on your current set-up is_numeric() seems to work fine.
>> It returns false, as expected.
>>
>
> No.
> is_numeric() returns true.
> It was var_dump() that reurned false.
>
>> But you claimed in your original post, the test returned true.
>> I am confused now. :-)
>
> Yes you are confused.
>
>> Could you give us the (relevant) code that made you make your first >
>> claim?
>
> $a = 'x11.11c';
> if(is_numeric($a)) { echo('oops - a problem' . '<BR>') } ;
>
>> I expect it does something else than you think it does.
>
> What it does is something that I didn't think right - as stated.
>
$ cat fool.php
<?php
$a = 'x11.11c';
if(is_numeric($a)) { echo('oops - a problem' . '<BR>'); }
?>EOL
$ php fool.php
EOL
I think you have a problem elsewhere in your code. is_numeric is
functioning correctly.
|
|
|
|
| Re: bug in is_numeric [message #181359 is a reply to message #181353] |
Mon, 13 May 2013 17:52 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2013 10:57 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > In contrast to what you stated, exactly *nothing* is wrong with it when
>>>> > properly quoted; that is, *in context*, which is the point. Giving you
>>>> > the benefit of a doubt, you appear to have severe difficulty
>>>> > understanding the concept of context as such and the importance of
>>>> > context in quotations specifically; it would be good if you could work
>>>> > on that.
>>>>
>>>> That was the beginning of your reply. There was no previous context to
>>>> quote.
>>>
>>> It was the text that *followed*, and that you snipped, that put the part
>>> of my statement that you quoted, in context.
>>
>> The statement was wrong in ANY context. […]
>
> No, it was and is not.
>
Yes, but you're too stoopid to understand that and/or too stubborn to
admit you are wrong.
>> You would have been much better off just admitting your statement was
>> wrong and moving on. But your ego doesn't allow that.
>
> It has nothing to do with ego to explain to you why you misinterpret my
> statement. It has to do with being honest, a concept that you appear to
> have problems with.
>
It has everything to do with your tremendous ego that you keep insisting
your code is correct - when any beginner who understands the least bit
about PHP knows it is not.
But once again you're making a fool of yourself. You make incorrect
statements and go off on completely unrelated tangents - as a weak
attempt to prove your competence. It does just the opposite.
But the that's just like you. It's why you are so well known as a troll
in many newsgroups.
But then I'm not going to stroke your ego any more, Pointed Head. Get a
job washing dishes - it's more within your capabilities.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181360 is a reply to message #181352] |
Mon, 13 May 2013 17:55 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 13/05/13 16:15, fred wrote:
> Otherwise I'm done repeating myself.
>>> if(is_numeric('x11.11c') returns TRUE
>>> and variations eg: z1111x is also true
> >
>> Could you try the following code and let me know what comes out?
>> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
>
> OK I get false when I do that.
> "bool(false)" to be more precise.
> var_export($a)also reports false if thats any help.
>
> 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.
Apparently there is nothing wrong with your is_numeric() as you state
var_export did return "bool(false)" which is the expected result.
you fail to show the code you actually used (the example you gave don't
have correct syntax, so I doubt it's from your actual code, just
something you wrote).
As other already pointed out, you are most likely expecting a specific
value to been set, but most likely it's another value (bad coding which
uses "global" values which are used in many functions will in most cases
have a more random nature of what value it will have) or that your
if-statement includes a negation for example:
if(!is_numeric("abcdef")) {
echo "my code is buggy, not is_numeric()\n";
}
By the way, var_export() don't return false, it will return null by
default or a string (if you set the return argument to true).
If you made a check on what var_export() returned and you got it to be
equal to false, then your method of checking the return value is utterly
flawed.
The release of PHP 5.3.6 is over two years ago, and if there had been a
bug, then it had been discovered a lot earlier than now on a function
which is heavily used in a lot of PHP code and the code base isn't
platform dependent.
My recommendation would be to upgrade to 5.4.14, if you can't find it
for your OS, then upgrade to one which provides it.
--
//Aho
|
|
|
|
| Re: bug in is_numeric [message #181362 is a reply to message #181359] |
Mon, 13 May 2013 18:28 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 5/13/2013 10:57 AM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >> In contrast to what you stated, exactly *nothing* is wrong with it
>>>> >> when
>>>> >> properly quoted; that is, *in context*, which is the point. Giving
>>>> >> you the benefit of a doubt, you appear to have severe difficulty
>>>> >> understanding the concept of context as such and the importance of
>>>> >> context in quotations specifically; it would be good if you could
>>>> >> work on that.
>>>> > That was the beginning of your reply. There was no previous context
>>>> > to quote.
>>>> It was the text that *followed*, and that you snipped, that put the
>>>> part of my statement that you quoted, in context.
>>> The statement was wrong in ANY context. […]
>> No, it was and is not.
>
> Yes, […]
No. It is the context provided by the following text, that you did not
quote, in which it is correct, as I was explaining how the string content
would be parsed (up to a point) if used verbatim.
>>> You would have been much better off just admitting your statement was
>>> wrong and moving on. But your ego doesn't allow that.
>>
>> It has nothing to do with ego to explain to you why you misinterpret my
>> statement. It has to do with being honest, a concept that you appear to
>> have problems with.
>
> It has everything to do with your tremendous ego that you keep insisting
> your code is correct […]
My code is correct because it executes. But that is just another red
herring of yours: My *code* was never at issue before in this discussion.
My *explanation* as to *why* the argument to is_numeric() here cannot be
considered numeric is correct because the tests – with the PHP CLI, for
crying out loud – clearly show that it is. What is wrong here is only your
interpretation of my explanation.
Unfortunately, you are in the habit to accept only your (wrong)
interpretations of texts as their true meaning, regardless of what their
original authors or a third party has to say about them. The record shows.
So much for “ego”.
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
|
|
|
|
| Re: bug in is_numeric [message #181364 is a reply to message #181332] |
Mon, 13 May 2013 20:15 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 12 May 2013 18:41:33 +0100, fred wrote:
> In article <kmocju$232o$1(at)yojimbo(dot)hack>, sal(at)yojimbo(dot)hack(dot)invalid
> says...
>> You are correct. That parameter, when passed to is_numeric(), should
>> return false. I tried it on Mac OS X and FreeBSD, but not on Windows.
>>
>> Could you try the following code and let me know what comes out?
>> <?php $a = is_numeric('x11.11c'); var_dump($a); ?>
>
> Hi sal
>
> OK I get false when I do that.
> "bool(false)" to be more precise.
> var_export($a)also reports false if thats any help.
OK, that tells us that on your computer and php version, the test:
is_numeric('x11.11c');
returns the boolean value FALSE, not the boolean value TRUE as you stated
earlier.
Note - you did the test on your computer using the exact same operating
system and php version that you are using.
So, the issue now is not that we are not using the exact same php / os,
but why you think that specific test is getting a TRUE when it's getting
a FALSE.
Personally, I'd guess that 'x11.11c' is not the value that's being tested
when it gives what you think is an unexpected TRUE.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: bug in is_numeric [message #181367 is a reply to message #181350] |
Mon, 13 May 2013 20:26 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 13 May 2013 14:58:27 +0100, fred wrote:
> In article <5190d3a0$0$15991$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
> erwinmollerusenet(at)xs4all(dot)nl says...
>> So on your current set-up is_numeric() seems to work fine.
>> It returns false, as expected.
>>
>>
> No.
> is_numeric() returns true.
> It was var_dump() that reurned false.
>
>> But you claimed in your original post, the test returned true.
>> I am confused now. :-)
>
> Yes you are confused.
>
>> Could you give us the (relevant) code that made you make your first >
>> claim?
>
> $a = 'x11.11c';
> if(is_numeric($a)) { echo('oops - a problem' . '<BR>') } ;
>
>> I expect it does something else than you think it does.
>
> What it does is something that I didn't think right - as stated.
Your code was broken - it gave the following error:
PHP Parse error: syntax error, unexpected '}', expecting ',' or ';' in /
home/denis/programming/php/is_num_test.php on line 4
This is probably because you had ";" outside of "{}", but it does
indicate that the code you included in the post *CAN NOT* have been an
exact copy / paste of your working code!
You have also proved, by running a specific test on your computer as Sal
asked you to, that _your_ computer actually returns FALSE when testing
is_numeric('x11.11c')
So, the question remains, what is it in your code that is causing you to
get an unexpected result?
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: bug in is_numeric [message #181378 is a reply to message #181319] |
Tue, 14 May 2013 08:34 |
Sandman
Messages: 32
Registered: August 2011
Karma: 0
|
Member |
|
|
In article <MPG(dot)2bf9b5f139f7cb7d9896aa(at)news(dot)virginmedia(dot)com>,
fred <email(at)address(dot)com> wrote:
> if(is_numeric('x11.11c') returns TRUE
> and variations eg: z1111x is also true
Nope, as others have pointed out, works as it should:
sandman@dream ~> uname -a
Darwin dream.sandman.net 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6
22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
sandman@dream ~> php -v
PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
sandman@dream ~> php -r 'var_dump(is_numeric("x11.11c"));'
bool(false)
--
Sandman[.net]
|
|
|
|
| Re: bug in is_numeric [message #181379 is a reply to message #181352] |
Tue, 14 May 2013 13:41 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)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)
|
|
|
|
| Re: bug in is_numeric [message #181380 is a reply to message #181378] |
Tue, 14 May 2013 13:47 |
fred
Messages: 7
Registered: May 2013
Karma: 0
|
Junior Member |
|
|
I can't work out if you're all a bunch of mentally deficient half wits
or just too stupid to run a correct test.
Either way its been reported I'm no longer interested.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]