bug in is_numeric

[fred]

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

[Salvatore]

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++

[Luuk]

On 12-05-2013 17:31, Salvatore wrote:
> On 2013-05-12, fred <em...@address.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)

[Luuk]

On 12-05-2013 17:31, Salvatore wrote:

> On 2013-05-12, fred <em...@address.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>

[Thomas 'PointedEars' Lahn]

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

[Thomas Mlynarczyk]

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)

[Denis McMahon]

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, denismf...@gmail.com

[Sanders Kaufman]

"fred" wrote in message
news:MPG.2bf9b5f13...@news.virginmedia.com...

>if(is_numeric('x11.11c') returns TRUE

Try it without the quotation marks around the number.
Quotes turn a number into a string.

[Luuk]

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

[Thomas Mlynarczyk]

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)

[fred]

In article <2669113.c...@PointedEars.de>, Point...@web.de
says...
>

plonk.

life is too short.

>

[Thomas 'PointedEars' Lahn]

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

[Thomas 'PointedEars' Lahn]

fred wrote:

> In article <2669113.c...@PointedEars.de>, Point...@web.de
> says...
>>
>
> plonk.

YMMD.

> life is too short.

A simple “Yes.” would have sufficed.


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

[fred]

In article <kmocju$232o$1...@yojimbo.hack>, s...@yojimbo.hack.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.

[Thomas 'PointedEars' Lahn]

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 […]

[Robert Heller]

At Sun, 12 May 2013 15:31:10 +0000 (UTC) Salvatore <s...@yojimbo.hack.invalid> wrote:

>
> On 2013-05-12, fred <em...@address.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 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

[Jerry Stuckle]

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.
jstu...@attglobal.net
==================

[Thomas 'PointedEars' Lahn]

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

[Luuk]

On 12-05-2013 19:40, Thomas 'PointedEars' Lahn wrote:
> fred wrote:
>
>> In article <2669113.c...@PointedEars.de>, Point...@web.de
>> says...
>>>
>>
>> plonk.
>
> YMMD.
>
>> life is too short.
>
> A simple “Yes.” would have sufficed.
>
>
> PointedEars
>

yes, Thomas, you are.....

[Jerry Stuckle]

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...

[Thomas 'PointedEars' Lahn]

> 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.)

[Jerry Stuckle]

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.

[Thomas 'PointedEars' Lahn]

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

[Erwin Moller]

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

[Jerry Stuckle]

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.

[fred]

In article <5190d3a0$0$15991$e4fe...@news2.news.xs4all.nl>,
erwinmol...@xs4all.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.

[Jerry Stuckle]

On 5/13/2013 9:58 AM, fred wrote:
> In article <5190d3a0$0$15991$e4fe...@news2.news.xs4all.nl>,
> erwinmol...@xs4all.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';

[fred]

In article <kmqs3c$e3s$1...@dont-email.me>, jstu...@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.

[Thomas 'PointedEars' Lahn]

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$8300...@news.demon.co.uk>

[Thomas 'PointedEars' Lahn]

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$8300...@news.demon.co.uk> (2004)

[Erwin Moller]

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.

[Daniel Pitts]

$ 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.

[Jerry Stuckle]

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.

[J.O. Aho]

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

[Thomas 'PointedEars' Lahn]

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”.

[Denis McMahon]

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, denismf...@gmail.com

[Denis McMahon]

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, denismf...@gmail.com

[Sandman]

In article <MPG.2bf9b5f13...@news.virginmedia.com>,

fred <em...@address.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]

[Richard Yates]

<?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)

[fred]

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.

[Denis McMahon]

You seem to have totally missed the points that are being made:

1) The test you ran on your system (this is the code that Sal asked you
to run) gave a correct result for the test case you specified.
Specifically it returned boolean value FALSE for an is_numeric() test of
the string value "x11.11c".

2) The code that you posted here as a specific example of failing code
was obviously not the code that is actually failing, because it was
syntatically broken php. Specifically it had a terminating ";" outside of
the braces "{}" that enclosed the print statement following the test
condition in the if clause.

At the moment, the only "evidence" for the problem is your original
assertion, which is not supported by the specific test case that Sal
asked you to execute, and which was based on the exact error that you
originally asserted.

Yes we would like to help you solve the problem, but so far, you have not
shown any evidence that the problem is any sort of bug in is_numeric. If
anything, the test case that Sal gave you proves that on your machine,
under the conditions that you specified, is_numeric is working properly.

The conclusion is that the case that's causing what you perceive to be an
error condition isn't the case that you originally or subsequently
stated, and unless you tell us what the actual code is that causes what
you perceive to be an error, there's very little we can do to help.

My suspicion is that although for some reason you think the string value
"x11.11c" is being passed to the test function is_numeric, some other
value is actually being passed.

--
Denis McMahon, denismf...@gmail.com

[SwissCheese]

That's backwards... you want:

$a = 'x11.11c';
if(is_numeric($a)) { echo 'ok'; } else { ec

--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[SwissCheese]

On 05/14/2013 09:41 AM, Richard Yates wrote:

That's backwards... you want:

$a = 'x11.11c';
if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }

Sorry, hit send too quick!

[Jerry Stuckle]

No, Richard had it correct. The if statement returns false, which is
'ok'. Your code would return 'not ok' - which is incorrect.

[Sandman]

In article <MPG.2bfc50d78...@news.virginmedia.com>,

fred <em...@address.com> wrote:

> 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.

A "correct test" has been run by almost ten people now.

> Either way its been reported I'm no longer interested.

--
Sandman[.net]

[SwissCheese]

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."

[Jerry Stuckle]

Yes, I know how is_numeric() works. But you don't understand what his
code was doing.

Saying 'not ok' indicates is_numeric is broken - not that the value is
not numeric. is_numeric() is not broken, so saying 'not ok' is the
incorrect message.

It is not saying the value is numeric.

[Jerry Stuckle]

My suspicion is that he found his problem, and it was not in
is_numeric(). But he doesn't want to admit it.

Nothing's been reported in the bugs database for the last week.

[Erwin Moller]

On 5/15/2013 12:27 PM, Jerry Stuckle wrote:
> On 5/15/2013 2:05 AM, Sandman wrote:
>> In article <MPG.2bfc50d78...@news.virginmedia.com>,
>> fred <em...@address.com> wrote:
>>
>>> 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.
>>
>> A "correct test" has been run by almost ten people now.
>>
>>> Either way its been reported I'm no longer interested.
>>
>>
>>
>>
>
> My suspicion is that he found his problem, and it was not in
> is_numeric(). But he doesn't want to admit it.

Yes, I suspect the same.
This Fred seems to have some attitude issues.
He is propably too proud to admit he screwed up the variable to be tested.

Well, not a big loss IMHO, since he lacked the logical skills to see
that he showed himself with Salvatore's test that his is_numeric()
worked alright. ;-)


Regards,
Erwin Moller

>
> Nothing's been reported in the bugs database for the last week.
>




--

[Thomas 'PointedEars' Lahn]

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). It is not possible to determine by
testing whether the octal format is considered numeric because of itself or
because it is considered decimal. Incidentally, you have neglected to test
those two formats.

[Christoph Becker]

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

[Thomas 'PointedEars' Lahn]

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:Xns9FB6521286...@94.75.214.39>

[Christoph Becker]

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

[Thomas 'PointedEars' Lahn]

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).

[Christoph Becker]

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

[Thomas Mlynarczyk]

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)

[Christoph Becker]

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

[Christoph Becker]

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

[SwissCheese]

On 05/14/2013 11:01 PM, Jerry Stuckle wrote:

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.

[Thomas 'PointedEars' Lahn]

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.

[Jerry Stuckle]

'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.

[SwissCheese]

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

[SwissCheese]

On 05/13/2013 05: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 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.
>

is_numeric() checks to see if the first two characters are '0x' (or
'0X'), but it does not add a leading '0' if the first character is an
'x' (or 'X')... nor does it simply omit the part that is not a number
'.11c'. is_numeric() checks the string as passed without altering it.

>>> 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.
>>

Correct as per my other reply.

>> 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

[Thomas 'PointedEars' Lahn]

SwissCheese wrote:

> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>> 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.
>
> is_numeric() checks to see if the first two characters are '0x' (or
> '0X'), but it does not add a leading '0' if the first character is an
> 'x' (or 'X')... nor does it simply omit the part that is not a number
> '.11c'. is_numeric() checks the string as passed without altering it.

Aside from getting a real name and learning to quote only the relevant parts
of what you are replying to, you want to learn to read what you quote more
carefully. I have not even implied that is_numeric() adds anything.

>>>> 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.
>
> Correct as per my other reply.

It is not correct if the manual says something else, and it does. Either
the manual or the implementation is wrong.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[SwissCheese]

You know, I've only had to read this post ten times to understand
what you were saying... ;) My thought was that the output was saying the
argument was 'ok' (a number) or 'not ok' (not a number'). I did not
consider the output to be a reflection of the status of is_numeric().

[SwissCheese]

On 05/14/2013 11:01 PM, Jerry Stuckle wrote:

As per my other reply... my code returns 'not ok' because 'x11.11c'
as a string being evaluated by is_numeric() is not ok. It does not pass
as a valid number. 'not ok' -> 'not numeric'

[Thomas 'PointedEars' Lahn]

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?

[Christoph Becker]

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

[Jerry Stuckle]

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.

[SwissCheese]

On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>>> 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.
>>
>> is_numeric() checks to see if the first two characters are '0x' (or
>> '0X'), but it does not add a leading '0' if the first character is an
>> 'x' (or 'X')... nor does it simply omit the part that is not a number
>> '.11c'. is_numeric() checks the string as passed without altering it.
>
> Aside from getting a real name and learning to quote only the relevant parts
> of what you are replying to, you want to learn to read what you quote more
> carefully. I have not even implied that is_numeric() adds anything.
>

Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
of -your- real name, maybe you would notice that my real name is in my
signature.

>>>>> 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.
>>
>> Correct as per my other reply.
>
> It is not correct if the manual says something else, and it does. Either
> the manual or the implementation is wrong.
>
>

'Correct' in that the documentation is wrong... as I stated in another
reply.

[SwissCheese]

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?

[Thomas 'PointedEars' Lahn]

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

[Christoph Becker]

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

[Thomas 'PointedEars' Lahn]

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.

[Thomas 'PointedEars' Lahn]

SwissCheese wrote:

> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>>>>> 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.
>>> is_numeric() checks to see if the first two characters are '0x' (or
>>> '0X'), but it does not add a leading '0' if the first character is an
>>> 'x' (or 'X')... nor does it simply omit the part that is not a number
>>> '.11c'. is_numeric() checks the string as passed without altering it.
>> Aside from getting a real name and learning to quote only the relevant
>> parts of what you are replying to, you want to learn to read what you
>> quote more carefully. I have not even implied that is_numeric() adds
>> anything.
>
> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
> of -your- real name,

It's “PointedEars”, stupid, without the space. And it is customary to
include the nickname in the From header field value as I did.

> maybe you would notice that my real name is in my signature.

A real name consists of first *and* last name; it belongs in the From header
field value first, and you are evading the issue of your misconception.

>>>>>> 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.
>>>
>>> Correct as per my other reply.
>>
>> It is not correct if the manual says something else, and it does. Either
>> the manual or the implementation is wrong.
>
> 'Correct' in that the documentation is wrong... as I stated in another
> reply.

No, you did not.


Score adjusted

[Norman Peelman]

On 05/18/2013 04:28 AM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:

>>> Aside from getting a real name and learning to quote only the relevant
>>> parts of what you are replying to, you want to learn to read what you
>>> quote more carefully. I have not even implied that is_numeric() adds
>>> anything.
>>
>> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
>> of -your- real name,
>
> It's “PointedEars”, stupid, without the space. And it is customary to
> include the nickname in the From header field value as I did.
>

...not really sure why you have decided to attack me/start name calling
but whatever.

>> maybe you would notice that my real name is in my signature.
>
> A real name consists of first *and* last name; it belongs in the From header
> field value first, and you are evading the issue of your misconception.
>

...sorry, I was not aware there were so many rules. I have yet to see an
e-mail/news-reader client that explains them while setting up a Usenet
account.

>>>>>>> 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.
>>>>
>>>> Correct as per my other reply.
>>>
>>> It is not correct if the manual says something else, and it does. Either
>>> the manual or the implementation is wrong.
>>
>> 'Correct' in that the documentation is wrong... as I stated in another
>> reply.
>
> No, you did not.
>

Well, it appears to have landed in the bit-bucket as I can't find it
either. In any regard, I was agreeing with you that there is a mismatch.

>
> Score adjusted
>
> PointedEars
>

...not keeping score.

[Luuk]

On 18-05-2013 14:00, Norman Peelman wrote:
>> A real name consists of first *and* last name; it belongs in the From
>> header
>> field value first, and you are evading the issue of your misconception.
>>
>
> ...sorry, I was not aware there were so many rules. I have yet to see an
> e-mail/news-reader client that explains them while setting up a Usenet
> account.

It's not a 'rule'....
It maybe more polite, but that's a different discussion.....

--
Luuk

[Jerry Stuckle]

On 5/18/2013 8:00 AM, Norman Peelman wrote:
>
> ...sorry, I was not aware there were so many rules. I have yet to see an
> e-mail/news-reader client that explains them while setting up a Usenet
> account.
>

There aren't. These are just Pointed Heads way of proving his manhood.
Most others don't care as long as you're not trolling.

But then he's well known for this in several newsgroups, not just this one.

Go ahead and use a nick if you want - and ignore Pointed Head. He's not
worth the trouble.

[Christoph Becker]

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

[Christoph Becker]

Jerry Stuckle wrote:
> 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.

Does it really matter if the issue is pointed out in this thread or in a
new thread with the subject "bug in is_numeric"? And does it matter who
files a respective bug report? After all, we all benefit from being PHP
as bug free/clearly documented as possible.

--
Christoph M. Becker

[The Natural Philosopher]

On 18/05/13 13:00, Norman Peelman wrote:
>
>> A real name consists of first *and* last name; it belongs in the From
>> header
>> field value first, and you are evading the issue of your misconception.
>>
>
> ...sorry, I was not aware there were so many rules. I have yet to see
> an e-mail/news-reader client that explains them while setting up a
> Usenet account.
>

There are no rules. There is accepted custom and practice and personal
decisions toted as standards, by the likes of pointy rears.

There are very very good reasons to remain casually anonymous on Usenet.
If you stray into any areas that arouse strong passions.

--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[Jerry Stuckle]

Yes, it does. People looking through threads will not find this problem
if they look at the first couple of posts. And people looking at the
first couple of posts will have to sort through a huge amount of garbage
to figure out most of what is here is completely unrelated to the
original subject.

Usenet has threads for a reason. And this is a perfect example why.
Maybe if Pointed Head weren't so caught up in criticizing everyone else
for what he perceives as egracious errors (like not using their real
name in their header) he could figure out how not to hijack others' threads.

[Thomas 'PointedEars' Lahn]

Norman Peelman wrote:

> On 05/18/2013 04:28 AM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Aside from getting a real name and learning to quote only the relevant
>>>> parts of what you are replying to, you want to learn to read what you
>>>> quote more carefully. I have not even implied that is_numeric() adds
>>>> anything.
>>> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
>>> of -your- real name,
>> It's “PointedEars”, stupid, without the space. And it is customary to
>> include the nickname in the From header field value as I did.
>
> ...not really sure why you have decided to attack me/start name calling
> but whatever.

A pot calling the kettle black. You are giving yourself too much credit (or
too little, depending how you look at it).

>>> maybe you would notice that my real name is in my signature.
>>
>> A real name consists of first *and* last name; it belongs in the From
>> header field value first, and you are evading the issue of your
>> misconception.
>
> ...sorry, I was not aware there were so many rules

Just common sense, including basic courtesy.

> I have yet to see an e-mail/news-reader client that explains them while
> setting up a Usenet account.

I know of no such newsreader either (presumably the abilities mentioned
above were assumed), but the KNode (4.10.2 and previous versions) handbook
(under menu Help→KNode handbook, or F1 key) also has a chapter titled “A
journey in the World of Newsgroups”, which is instructive.

If necessary, you would probably find basic instructions for your
Thunderbird in its handbook (menu Help→Help Contents, or F1 key), or on
mozilla.com.

And then there is news.newusers.* and dozens of good Usenet guides on the
Web.


F'up2 poster

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.)

[Jerry Stuckle]

On 5/18/2013 9:05 AM, The Natural Philosopher wrote:
> On 18/05/13 13:00, Norman Peelman wrote:
>>
>>> A real name consists of first *and* last name; it belongs in the From
>>> header
>>> field value first, and you are evading the issue of your misconception.
>>>
>>
>> ...sorry, I was not aware there were so many rules. I have yet to see
>> an e-mail/news-reader client that explains them while setting up a
>> Usenet account.
>>
> There are no rules. There is accepted custom and practice and personal
> decisions toted as standards, by the likes of pointy rears.
>
> There are very very good reasons to remain casually anonymous on Usenet.
> If you stray into any areas that arouse strong passions.
>

Yea, trolls definitely have a desire to remain anonymous.

[Sanders Kaufman]

"Jerry Stuckle" wrote in message news:kn81o7$uq6$1...@dont-email.me...

>Usenet has threads for a reason. And this is a perfect example why. Maybe
>if Pointed Head weren't so caught up in criticizing everyone else

Usenet wasn't meant to be a discussion group at all - it was meant to be a
forum for uncensored reporting.
That's what the second N in NNTP stands for.
Threading is just an evolutionary remnant of it's SMTP heritage, and the
reason why Usenet devolved away from being a news forum.

[Jerry Stuckle]

You obviously haven't been around enough. It was a discussion forum back
the 70's when it was on ARPANET. It had threading back then, also.

But no matter what the original name was - TODAY'S use is what counts.
It is a threaded discussion group, and threads exist for a reason.

[Norman Peelman]

On 05/18/2013 10:07 AM, Jerry Stuckle wrote:
> On 5/18/2013 8:51 AM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> 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.
>>
>> Does it really matter if the issue is pointed out in this thread or in a
>> new thread with the subject "bug in is_numeric"? And does it matter who
>> files a respective bug report? After all, we all benefit from being PHP
>> as bug free/clearly documented as possible.
>>
>
> Yes, it does. People looking through threads will not find this problem
> if they look at the first couple of posts. And people looking at the
> first couple of posts will have to sort through a huge amount of garbage
> to figure out most of what is here is completely unrelated to the
> original subject.
>

Of which I was inarguably part of... sorry about that.

> Usenet has threads for a reason. And this is a perfect example why.
> Maybe if Pointed Head weren't so caught up in criticizing everyone else
> for what he perceives as egracious errors (like not using their real
> name in their header) he could figure out how not to hijack others'
> threads.
>
>


--

[Thomas 'PointedEars' Lahn]

Sanders Kaufman wrote:

> Usenet wasn't meant to be a discussion group at all - it was meant to be a
> forum for uncensored reporting.
> That's what the second N in NNTP stands for.
> Threading is just an evolutionary remnant of it's SMTP heritage, and the
> reason why Usenet devolved away from being a news forum.

Utter nonsense. I wonder who is writing your textbooks.

[Thomas 'PointedEars' Lahn]

Jerry Stuckle wrote:

> On 5/18/2013 12:56 PM, Sanders Kaufman wrote:
>> "Jerry Stuckle" wrote in message news:kn81o7$uq6$1...@dont-email.me...
>>> Usenet has threads for a reason. And this is a perfect example why.
>>> Maybe if Pointed Head weren't so caught up in criticizing everyone else
>>
>> Usenet wasn't meant to be a discussion group at all - it was meant to be
>> a forum for uncensored reporting.
>> That's what the second N in NNTP stands for.
>> Threading is just an evolutionary remnant of it's SMTP heritage, and the
>> reason why Usenet devolved away from being a news forum.
>
> You obviously haven't been around enough.

Pot, kettle, black.

> It was a discussion forum back the 70's when it was on ARPANET. It had
> threading back then, also.

Although the NetNews Message Format nowadays (RFC 5536) is based on the
Internet Message Format (currently, RFC 5322), Usenet has always existed
separately from ARPAnet, and its successor, the Internet. The first Usenet
uaers used UUCP, not NNTP, and even NNTP is not required to use the Internet
infrastructure.

> But no matter what the original name was - TODAY'S use is what counts.

It is customary in Usenet to use *bold*, /italic/, or _underlined_ for
emphasis. Writing in all-caps is considered shouting instead, and therefore
impolite.

> It is a threaded discussion group, and threads exist for a reason.

“Thread drift”, as it is called, is normal and accepted on Usenet,
*especially* today. It has become that normal more than a decade ago that a
convention for change of Subject in the same thread (“New Subject (was: Old
Subject, without ‘Re:’)”) was implemented by several newsreaders, so that
the “ (was: …)” part was automatically removed from the Subject on replying.
People complaining about “thread hijacking” simply have no clue what they
are talking about. You will find that misconception predominantly among
people who are new to Usenet, who often come from Web forums, but there are
exceptions.

In this case there was not even thread drift as the Subject still fits the
content. Thread drift was initiated instead by the person complaining about
it. Honi soit qui mal y pense.

(Don't bother to reply.)

[Jerry Stuckle]

On 5/18/2013 4:24 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/18/2013 12:56 PM, Sanders Kaufman wrote:
>>> "Jerry Stuckle" wrote in message news:kn81o7$uq6$1...@dont-email.me...
>>>> Usenet has threads for a reason. And this is a perfect example why.
>>>> Maybe if Pointed Head weren't so caught up in criticizing everyone else
>>>
>>> Usenet wasn't meant to be a discussion group at all - it was meant to be
>>> a forum for uncensored reporting.
>>> That's what the second N in NNTP stands for.
>>> Threading is just an evolutionary remnant of it's SMTP heritage, and the
>>> reason why Usenet devolved away from being a news forum.
>>
>> You obviously haven't been around enough.
>
> Pot, kettle, black.
>

Been around a lot longer than you, Pointed Head. And a lot more
experience than you, also.

>> It was a discussion forum back the 70's when it was on ARPANET. It had
>> threading back then, also.
>
> Although the NetNews Message Format nowadays (RFC 5536) is based on the
> Internet Message Format (currently, RFC 5322), Usenet has always existed
> separately from ARPAnet, and its successor, the Internet. The first Usenet
> uaers used UUCP, not NNTP, and even NNTP is not required to use the Internet
> infrastructure.
>

Wrong, ARPANET and its successor, the Internet, are transport
mechanisms. Usenet ran over ARPANET in the 70's, and currently runs
over the Internet.

Except in your part of the world, where it seems to be transmitted by
sticks beating on hollow logs.

Or maybe your mommy took away your Internet access...

>> But no matter what the original name was - TODAY'S use is what counts.
>
> It is customary in Usenet to use *bold*, /italic/, or _underlined_ for
> emphasis. Writing in all-caps is considered shouting instead, and therefore
> impolite.
>

No, it is YOUR custom to emphasize with bold, italic, or whatever -
things which require HTML. But since HTML is NOT recommended for
Usenet, none of these are recommended.

Instead, limited use of all caps is considered by virtually EVERYONE
ELSE to be emphasis. Only TROLLS like POINTED HEAD complain about such
trivial things.

But then if you couldn't complain about such things, you wouldn't be
able to post without showing even more ignorance.

You are well known to do such in multiple newsgroups.

>> It is a threaded discussion group, and threads exist for a reason.
>
> “Thread drift”, as it is called, is normal and accepted on Usenet,
> *especially* today. It has become that normal more than a decade ago that a
> convention for change of Subject in the same thread (“New Subject (was: Old
> Subject, without ‘Re:’)”) was implemented by several newsreaders, so that
> the “ (was: …)” part was automatically removed from the Subject on replying.
> People complaining about “thread hijacking” simply have no clue what they
> are talking about. You will find that misconception predominantly among
> people who are new to Usenet, who often come from Web forums, but there are
> exceptions.
>

Thread drift is not the same as thread hijacking.

> In this case there was not even thread drift as the Subject still fits the
> content. Thread drift was initiated instead by the person complaining about
> it. Honi soit qui mal y pense.
>
> (Don't bother to reply.)
>
>
> PointedEars
>

What the topic says is immaterial. It all has to do with the OP's
original question. Your posts were completely unrelated to the OP's
problem, and you hijacked the thread,.

But once again, you are well known in multiple newsgroups for thread
hijacking and similar actions. You seem to have a very difficult time
staying on topic.

[Denis McMahon]

On Sat, 18 May 2013 14:32:53 -0400, Jerry Stuckle wrote:

> But no matter what the original name was - TODAY'S use is what counts.
> It is a threaded discussion group, and threads exist for a reason.

Technically threading is a client feature by virtue of how client
software uses and displays the references and in-reply-to headers on the
individual messages.

As neither of those headers is mandatory in newsgroup messages, the
newsgroup as such, technically, is not in and of itself threaded, rather
it is a group in which threaded discussions may be posted.

--
Denis McMahon, denismf...@gmail.com

[Sanders Kaufman]

"Jerry Stuckle" wrote in message news:kn8h95$khj$1...@dont-email.me...

>You obviously haven't been around enough. It was a discussion forum back
>the 70's when it was on ARPANET. It had threading back then, also.

Personal attack not withstanding - nobody claimed otherwise.
So, you're just arguing with yourself.

[Sanders Kaufman]

"Jerry Stuckle" wrote in message news:kn8h95$khj$1...@dont-email.me...

> It is a threaded discussion group, and threads exist for a reason.

Yupper - and that reason is to allow the discussion to morph as it will.
No hall monitor can stop it.

[Sanders Kaufman]

"Thomas 'PointedEars' Lahn" wrote in message
news:3010429.6...@PointedEars.de...

>> Threading is just an evolutionary remnant of it's SMTP heritage, and the
>> reason why Usenet devolved away from being a news forum.

> Utter nonsense. I wonder who is writing your textbooks.

It's okay for you not to believe the things you see.
The world needs janitors.

[Thomas 'PointedEars' Lahn]

Sanders Kaufman wrote:

> "Thomas 'PointedEars' Lahn" wrote […]

>>> Threading is just an evolutionary remnant of it's SMTP heritage, and the
>>> reason why Usenet devolved away from being a news forum.
>>
>> Utter nonsense. I wonder who is writing your textbooks.
>
> It's okay for you not to believe the things you see.
> The world needs janitors.

Please read <http://en.wikipedia.org/wiki/Usenet> pp. and shut up until you
have gotten a minimum clue of what you are talking about. Usenet was
conceived in 1979 by two graduate studends and started out in 1980 at two
U.S. universities as a discussion forum for scientists to exchange ideas.
Initially Unix-to-Unix-CoPy (UUCP, conceived in 1979) was used, then NNTP
(1986). SMTP came *after* Usenet was implemented, in 1982.

[The Natural Philosopher]

I see jerry is totally wrong, as usual

Thank Clapton for killfiles

[Jerry Stuckle]

Nope. RFC1036 defines the "References" header used to refer to a
previous message. It is a part of the Use net protocol.

Clients may or may not take advantage of the "References" header - but
it is not a "client feature".

[Jerry Stuckle]

Incorrect. To quote you:

"Usenet wasn't meant to be a discussion group at all - it was meant to
be a forum for uncensored reporting.
That's what the second N in NNTP stands for.
Threading is just an evolutionary remnant of it's SMTP heritage, and the
reason why Usenet devolved away from being a news forum. "

That is completely incorrect.

[Jerry Stuckle]

And this is a perfect example of why thread hijacking is frowned upon.