FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » bug in is_numeric
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: bug in is_numeric [message #181341 is a reply to message #181340] Mon, 13 May 2013 09:07 Go to previous messageGo to previous message
Thomas 'PointedEars' is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
Senior Member
Jerry Stuckle wrote:

> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >> Thomas Mlynarczyk wrote:
>>>> >>> Sanders Kaufman schrieb:
>>>> >>>>> if(is_numeric('x11.11c') returns TRUE
>>>> >>>> Try it without the quotation marks around the number.
>>>> >>>
>>>> >>> Which number? x11.11c is not a number.
>>>> >>
>>>> >> The misconception might partially draw from the fact that 0x11 is a
>>>> >> number, the hexadecimal representation of decimal 16¹ + 16⁰ = 17
>>>> >> (even in PHP).

To be clear, I was referring to *Sanders'* misconception.

>>>> >> In other programming languages that require a leading
>>>> >> “0” and do not have “.” as (concatenation) operator,
>>>> >>
>>>> >> x11.11c
>>>> >>
>>>> >> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> >> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> >> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> >> errors [1]).
>>>> >>
>>>> >> In PHP, however,
>>>> >>
>>>> >> x11.11c
>>>> >>
>>>> >> would be equivalent to
>>>> >>
>>>> >> (x11) . (11c)
>>>> >>
>>>> >
>>>> > Wrong, as usual.
>>>> >
>>>> > <snip>
>>>>
>>>> Intentionally misquoted, as usual.
>>>
>>> And exactly what is wrong with what I quoted?
>>
>> In contrast to what you stated, exactly *nothing* is wrong with it when
>> properly quoted; that is, *in context*, which is the point. Giving you
>> the benefit of a doubt, you appear to have severe difficulty
>> understanding the concept of context as such and the importance of
>> context in quotations specifically; it would be good if you could work on
>> that.
>
> That was the beginning of your reply. There was no previous context to
> quote.

It was the text that *followed*, and that you snipped, that put the part of
my statement that you quoted, in context.

>>> The rest of your trash
>>
>> Not everything that you choose to ignore or fail to understand is “trash”
>> because of that.
>
> No, but almost *everything* you say is pure tripe. You can't blame this
> on the "context".

You proceed from the false assumption that if someone is wrong on one thing
(and to date we have only *your* *opinion* on that) must be wrong on
another.

>>> was based on this incorrect premise; it would be a waste of bandwidth to
>>> repost your entire tripe.
>> As showed by the PHP output that I posted further below, and that you
>> snipped, the premise is _not_ incorrect. To elaborate:
>
> The premise is completely incorrect. 'x11.11c' is NEVER considered a
> numeric value, as several other people (including me) have shown. And
> the '.' is NEVER an operator when within a quoted string.

Apparently you do not understand that is_numeric() treats both numeric
literals and numeric representations in string literals the same. Therefore
it matters to the return value of is_numeric() if string content could be a
numeric literal when used verbatim in PHP code. I have showed that and why
it could not be a numeric literal, providing the rationale for the return
value of is_numeric().

>> As a result, “x11“ would be considered a constant's identifier; because
>> such a constant would likele be undeclared, it would be parsed as if it
>> was a string value containing the characters of the would-be identifier
>> as characters (see the PHP Notices in the test, and the generated output
>> for proof of that).
>
> Nope, not unless there was a define ('x11',...) statement previous to
> this. It is a string - plain and simple. […]

The PHP output that I posted shows that a standalone identifier – such *as
if* that string *content* was used in PHP code is met with a PHP Notice and
is *treated as* I described above from then on. The Notice is issued then
because the source code is ambiguous, therefore error-prone. As you
confirmed, if a constant having that sequence of identifiers would be
declared, the source code would change meaning.

This is important because if a sequence of characters is potentially a
constant identifier, it cannot be a numeric literal at the same time.

>> “11c” would be considered a constant identifier as well (and treated the
>> same way) if it did not start with a decimal digit. Or it would be
>> considered a decimal literal if it did not contain/end with “c” (allowed
>> would only be “e” followed by a decimal literal, for the
>> exponential/scientific decimal format). But as it does contain/end with
>> “c”
>> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
>> the entire expression would not compile and the entire PHP program would
>> not compile, being syntactically in error.
>
> Wrong again. In PHP you have to have a define() statement to create a
> constant. It is part of string. […]

I am aware that one needs define() for constants. This has nothing to do
with the fact that an identifier is treated as a string value containing the
identifiers characters if there is no constant declared with that
identifier. And it has nothing to do with the fact that a constant cannot
start with a decimal digit, or that a decimal literal cannot contain the
character “c”. That therefore such a PHP program would be syntactical in
error; that therefore, too, “x11.11c” cannot be a numeric literal, and that
therefore, too, is_numeric('x11.11c') MUST return FALSE (which, contrary to
the OP's claims, it does).

>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>> cannot be a proper numeric literal in PHP (it would be an operation
>> expression
>> [that would not compile, but that is unimportant from here]). As that is
>> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>
> No, it is a string value, nothing more, nothing less.

It is a string value whose suitability to serve as a numeric value is being
tested with is_numeric(). Therefore it matters what the PHP grammar has to
say about numeric values.

>> is_numeric('x11.11c')
>>
>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>
> is_numeric('0x11') has nothing to do with the problem at hand.

Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix make
“0x11” a proper numeric (hexadecimal integer) representation as per the PHP
grammar. Which is what is_numeric() is supposed to test.

>> However, there appears to be an *actual* mismatch between PHP manual and
>> implementation in said PHP version as
>>
>> is_numeric('0b11001001')
>>
>> returns FALSE when according to the manual it should return TRUE (binary
>> integer literals are available since PHP 5.4.0 per the manual, and they
>> do compile and properly evaluate in tests there.
>
> Again, absolutely nothing to do with this problem.

Yes, it has. The OP claimed there was a bug in is_numeric(). If we assume
the manual to be correct, this example shows that there actually *would be*
a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on Debian GNU/Linux).
But it would be *another* bug.

That might be immaterial to you, but I consider it important for my fellow
PHP developers to learn of it.


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

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: problem encrypting data (AES_ENCRYPT/AES_DECRYPT)
Next Topic: Debian: php fast-cgi along with mod_php
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Nov 23 06:53:13 GMT 2024

Total time taken to generate the page: 0.04364 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software