Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #9264 > unrolled thread
| Started by | fred <email@address.com> |
|---|---|
| First post | 2013-05-12 15:22 +0100 |
| Last post | 2013-05-15 13:11 +0200 |
| Articles | 20 on this page of 141 — 20 participants |
Back to article view | Back to comp.lang.php
bug in is_numeric fred <email@address.com> - 2013-05-12 15:22 +0100
Re: bug in is_numeric Salvatore <sal@yojimbo.hack.invalid> - 2013-05-12 15:31 +0000
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 17:55 +0200
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 17:58 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-12 18:06 +0200
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-12 16:24 +0000
Re: bug in is_numeric fred <email@address.com> - 2013-05-12 18:41 +0100
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-13 13:50 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-13 14:58 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 10:11 -0400
Re: bug in is_numeric fred <email@address.com> - 2013-05-13 15:15 +0100
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-13 17:29 +0200
Re: bug in is_numeric "J.O. Aho" <user@example.net> - 2013-05-13 19:55 +0200
Re: bug in is_numeric Richard Yates <richard@yatesguitar.com> - 2013-05-14 06:41 -0700
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-14 21:43 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-14 23:01 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-15 05:48 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-15 06:11 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:36 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 15:19 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 20:23 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 20:49 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 21:58 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-15 22:20 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-15 22:42 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-15 23:53 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-16 00:29 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-16 00:40 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-16 05:00 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:16 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 00:45 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 22:52 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 18:33 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-17 20:39 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 23:45 +0200
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-18 14:47 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-15 20:57 -0400
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-16 00:09 -0400
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-17 01:17 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-16 20:30 -0400
Re: bug in is_numeric Christoph Becker <cmbecker69@gmx.de> - 2013-05-18 14:51 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 10:07 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 11:56 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 14:32 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 22:24 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 17:01 -0400
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-18 21:58 +0000
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:21 -0400
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-19 02:22 +0000
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 22:41 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:28 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:42 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:42 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:39 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 01:01 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 05:59 -0400
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 07:49 +0100
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:31 -0500
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 12:39 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:43 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:52 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:42 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 01:03 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:00 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:45 -0500
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:27 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:45 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:37 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:43 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 00:59 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:02 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:08 -0500
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-18 23:58 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:22 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:11 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 19:23 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:35 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 09:46 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:23 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-19 14:44 -0400
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-21 00:54 -0500
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-21 06:03 -0400
Re: bug in is_numeric fred <email@address.com> - 2013-05-23 15:38 +0100
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-01 17:36 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-01 14:54 -0400
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 15:25 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 10:34 -0400
Re: bug in is_numeric Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 17:02 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 12:30 -0400
OT: What you say is not always what you mean (was: Re: bug in is_numeric) Arno Welzel <usenet@arnowelzel.de> - 2013-06-05 20:20 +0200
Re: OT: What you say is not always what you mean Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-05 14:40 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 21:51 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-18 17:13 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-19 00:49 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 05:24 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-19 12:40 +0200
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-19 12:43 +0100
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-19 11:29 -0500
Re: bug in is_numeric Norman Peelman <npeelman@cfl.rr.com> - 2013-05-18 14:53 -0400
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:41 -0400
Re: bug in is_numeric Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-13 08:35 -0700
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-13 20:26 +0000
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-13 20:15 +0000
Re: bug in is_numeric Robert Heller <heller@deepsoft.com> - 2013-05-12 13:03 -0500
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 18:03 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-12 18:34 +0100
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:40 +0200
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 21:51 +0200
Re: bug in is_numeric "Sanders Kaufman" <bucky@kaufman.net> - 2013-05-12 11:47 -0500
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-12 18:56 +0200
Re: bug in is_numeric Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-05-12 19:05 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:38 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 19:46 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 14:11 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 20:39 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 16:51 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 01:27 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-12 20:35 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 11:07 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 09:02 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 16:57 +0200
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 17:10 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-13 13:52 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-13 20:28 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 18:28 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-17 00:33 +0200
Re: bug in is_numeric SwissCheese <swisscheese@cfl.rr.com> - 2013-05-16 22:34 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 10:28 +0200
Re: bug in is_numeric Norman Peelman <npeelman@cfl.rr.com> - 2013-05-18 08:00 -0400
Re: bug in is_numeric Luuk <luuk@invalid.lan> - 2013-05-18 14:18 +0200
Re: bug in is_numeric Tim Streater <timstreater@greenbee.net> - 2013-05-18 13:20 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 08:47 -0400
Re: bug in is_numeric The Natural Philosopher <tnp@invalid.invalid> - 2013-05-18 14:05 +0100
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-18 10:16 -0400
Re: bug in is_numeric Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-18 16:14 +0200
Re: bug in is_numeric Sandman <mr@sandman.net> - 2013-05-14 10:34 +0200
Re: bug in is_numeric fred <email@address.com> - 2013-05-14 14:47 +0100
Re: bug in is_numeric Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-14 14:54 +0000
Re: bug in is_numeric Sandman <mr@sandman.net> - 2013-05-15 08:05 +0200
Re: bug in is_numeric Jerry Stuckle <jstucklex@attglobal.net> - 2013-05-15 06:27 -0400
Re: bug in is_numeric Erwin Moller <erwinmollerusenet@xs4all.nl> - 2013-05-15 13:11 +0200
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2013-05-13 08:35 -0700 |
| Message-ID | <sL7kt.12460$sY5.7426@newsfe10.iad> |
| In reply to | #9295 |
On 5/13/13 6:58 AM, fred wrote:
> In article <5190d3a0$0$15991$e4fe514c@news2.news.xs4all.nl>,
> erwinmollerusenet@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.
>
$ 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.
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-05-13 20:26 +0000 |
| Message-ID | <kmri9t$mqd$5@dont-email.me> |
| In reply to | #9295 |
On Mon, 13 May 2013 14:58:27 +0100, fred wrote:
> In article <5190d3a0$0$15991$e4fe514c@news2.news.xs4all.nl>,
> erwinmollerusenet@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.
Your code was broken - it gave the following error:
PHP Parse error: syntax error, unexpected '}', expecting ',' or ';' in /
home/denis/programming/php/is_num_test.php on line 4
This is probably because you had ";" outside of "{}", but it does
indicate that the code you included in the post *CAN NOT* have been an
exact copy / paste of your working code!
You have also proved, by running a specific test on your computer as Sal
asked you to, that _your_ computer actually returns FALSE when testing
is_numeric('x11.11c')
So, the question remains, what is it in your code that is causing you to
get an unexpected result?
--
Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-05-13 20:15 +0000 |
| Message-ID | <kmrhli$mqd$4@dont-email.me> |
| In reply to | #9277 |
On Sun, 12 May 2013 18:41:33 +0100, fred wrote:
> In article <kmocju$232o$1@yojimbo.hack>, sal@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.
OK, that tells us that on your computer and php version, the test:
is_numeric('x11.11c');
returns the boolean value FALSE, not the boolean value TRUE as you stated
earlier.
Note - you did the test on your computer using the exact same operating
system and php version that you are using.
So, the issue now is not that we are not using the exact same php / os,
but why you think that specific test is getting a TRUE when it's getting
a FALSE.
Personally, I'd guess that 'x11.11c' is not the value that's being tested
when it gives what you think is an unexpected TRUE.
--
Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Robert Heller <heller@deepsoft.com> |
|---|---|
| Date | 2013-05-12 13:03 -0500 |
| Message-ID | <StadnS_vDuUURBLMnZ2dnUVZ_vednZ2d@giganews.com> |
| In reply to | #9265 |
At Sun, 12 May 2013 15:31:10 +0000 (UTC) Salvatore <sal@yojimbo.hack.invalid> wrote:
>
> On 2013-05-12, fred <email@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 / heller@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-12 18:03 +0200 |
| Message-ID | <2669113.cW6KZbUgVD@PointedEars.de> |
| In reply to | #9264 |
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
[toc] | [prev] | [next] | [standalone]
| From | fred <email@address.com> |
|---|---|
| Date | 2013-05-12 18:34 +0100 |
| Message-ID | <MPG.2bf9e2dfd14786cb9896ab@news.virginmedia.com> |
| In reply to | #9268 |
In article <2669113.cW6KZbUgVD@PointedEars.de>, PointedEars@web.de says... > plonk. life is too short. >
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-12 19:40 +0200 |
| Message-ID | <2623838.5bHPnUisa5@PointedEars.de> |
| In reply to | #9274 |
fred wrote: > In article <2669113.cW6KZbUgVD@PointedEars.de>, PointedEars@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).
[toc] | [prev] | [next] | [standalone]
| From | Luuk <luuk@invalid.lan> |
|---|---|
| Date | 2013-05-12 21:51 +0200 |
| Message-ID | <qe856a-hvp.ln1@luuk.invalid.lan> |
| In reply to | #9276 |
On 12-05-2013 19:40, Thomas 'PointedEars' Lahn wrote: > fred wrote: > >> In article <2669113.cW6KZbUgVD@PointedEars.de>, PointedEars@web.de >> says... >>> >> >> plonk. > > YMMD. > >> life is too short. > > A simple “Yes.” would have sufficed. > > > PointedEars > yes, Thomas, you are.....
[toc] | [prev] | [next] | [standalone]
| From | "Sanders Kaufman" <bucky@kaufman.net> |
|---|---|
| Date | 2013-05-12 11:47 -0500 |
| Message-ID | <6JPjt.2779$7j7.1429@newsfe14.iad> |
| In reply to | #9264 |
"fred" wrote in message
news:MPG.2bf9b5f139f7cb7d9896aa@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.
[toc] | [prev] | [next] | [standalone]
| From | Luuk <luuk@invalid.lan> |
|---|---|
| Date | 2013-05-12 18:56 +0200 |
| Message-ID | <m6u46a-29n.ln1@luuk.invalid.lan> |
| In reply to | #9271 |
On 12-05-2013 18:47, Sanders Kaufman wrote:
>
>
> "fred" wrote in message
> news:MPG.2bf9b5f139f7cb7d9896aa@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.
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
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2013-05-12 19:05 +0200 |
| Message-ID | <kmoi50$bkc$1@news.albasani.net> |
| In reply to | #9271 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-12 19:38 +0200 |
| Message-ID | <1851737.v4KHZ1CCSF@PointedEars.de> |
| In reply to | #9273 |
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
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-12 19:46 +0200 |
| Message-ID | <1536050.N0pG7d5rYB@PointedEars.de> |
| In reply to | #9275 |
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 […]
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-12 14:11 -0400 |
| Message-ID | <kmolp6$pfl$1@dont-email.me> |
| In reply to | #9275 |
On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
> Thomas Mlynarczyk wrote:
>
>> Sanders Kaufman schrieb:
>>>> if(is_numeric('x11.11c') returns TRUE
>>> Try it without the quotation marks around the number.
>>
>> Which number? x11.11c is not a number.
>
> The misconception might partially draw from the fact that 0x11 is a number,
> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP). In
> other programming languages that require a leading “0” and do not have “.”
> as (concatenation) operator,
>
> x11.11c
>
> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 × 16⁻³ =
> 17.06958 (BTW, I have written a drop-in replacement for ECMAScript's
> parseFloat() that can do that, with the usual rounding errors [1]).
>
> In PHP, however,
>
> x11.11c
>
> would be equivalent to
>
> (x11) . (11c)
>
Wrong, as usual.
<snip>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-12 20:39 +0200 |
| Message-ID | <2674261.IiuJV7CBEH@PointedEars.de> |
| In reply to | #9280 |
Jerry Stuckle wrote:
> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>> Thomas Mlynarczyk wrote:
>>> Sanders Kaufman schrieb:
>>>>> if(is_numeric('x11.11c') returns TRUE
>>>> Try it without the quotation marks around the number.
>>>
>>> Which number? x11.11c is not a number.
>>
>> The misconception might partially draw from the fact that 0x11 is a
>> number,
>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>> In other programming languages that require a leading “0” and do not have
>> “.” as (concatenation) operator,
>>
>> x11.11c
>>
>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>> ECMAScript's parseFloat() that can do that, with the usual rounding
>> errors [1]).
>>
>> In PHP, however,
>>
>> x11.11c
>>
>> would be equivalent to
>>
>> (x11) . (11c)
>>
>
> Wrong, as usual.
>
> <snip>
Intentionally misquoted, as usual.
F'up2 where it belongs
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-12 16:51 -0400 |
| Message-ID | <kmov5q$i0a$1@dont-email.me> |
| In reply to | #9281 |
On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>> Thomas Mlynarczyk wrote:
>>>> Sanders Kaufman schrieb:
>>>>>> if(is_numeric('x11.11c') returns TRUE
>>>>> Try it without the quotation marks around the number.
>>>>
>>>> Which number? x11.11c is not a number.
>>>
>>> The misconception might partially draw from the fact that 0x11 is a
>>> number,
>>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>> In other programming languages that require a leading “0” and do not have
>>> “.” as (concatenation) operator,
>>>
>>> x11.11c
>>>
>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>> errors [1]).
>>>
>>> In PHP, however,
>>>
>>> x11.11c
>>>
>>> would be equivalent to
>>>
>>> (x11) . (11c)
>>>
>>
>> Wrong, as usual.
>>
>> <snip>
>
> Intentionally misquoted, as usual.
>
>
> F'up2 where it belongs
>
> PointedEars
>
And exactly what is wrong with what I quoted? The rest of your trash
was based on this incorrect premise; it would be a waste of bandwidth to
repost your entire tripe.
But then I guess you like to ride "my.little.pony", which is why you set
the FUP. You can't handle someone correcting your errors. Probably
because you are so seldom correct about anything.
Why don't you get a job where you can understand what's going on?
Hamburger flipper comes to mind...
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-13 01:27 +0200 |
| Message-ID | <16716194.HF93PK6e1C@PointedEars.de> |
| In reply to | #9283 |
Jerry Stuckle wrote:
> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Thomas Mlynarczyk wrote:
>>>>> Sanders Kaufman schrieb:
>>>>>>> if(is_numeric('x11.11c') returns TRUE
>>>>>> Try it without the quotation marks around the number.
>>>>>
>>>>> Which number? x11.11c is not a number.
>>>>
>>>> The misconception might partially draw from the fact that 0x11 is a
>>>> number,
>>>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>>> In other programming languages that require a leading “0” and do not
>>>> have “.” as (concatenation) operator,
>>>>
>>>> x11.11c
>>>>
>>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> errors [1]).
>>>>
>>>> In PHP, however,
>>>>
>>>> x11.11c
>>>>
>>>> would be equivalent to
>>>>
>>>> (x11) . (11c)
>>>>
>>>
>>> Wrong, as usual.
>>>
>>> <snip>
>>
>> Intentionally misquoted, as usual.
>
> And exactly what is wrong with what I quoted?
In contrast to what you stated, exactly *nothing* is wrong with it when
properly quoted; that is, *in context*, which is the point. Giving you the
benefit of a doubt, you appear to have severe difficulty understanding the
concept of context as such and the importance of context in quotations
specifically; it would be good if you could work on that.
> The rest of your trash
Not everything that you choose to ignore or fail to understand is “trash”
because of that.
> was based on this incorrect premise; it would be a waste of bandwidth to
> repost your entire tripe.
As showed by the PHP output that I posted further below, and that you
snipped, the premise is _not_ incorrect. To elaborate:
“.” would be considered a concatenation operator here; there is no other
production of the PHP grammar that fits the source code better. Numeric
literals must not start with “x” in PHP, which precludes the possibility
that “.” would be parsed as a decimal point of the literal “x11.11” (which,
giving you the benefit of a doubt, might have been your assumption drawing
from other programming languages that you might know).
As a result, “x11“ would be considered a constant's identifier; because such
a constant would likele be undeclared, it would be parsed as if it was a
string value containing the characters of the would-be identifier as
characters (see the PHP Notices in the test, and the generated output for
proof of that).
“11c” would be considered a constant identifier as well (and treated the
same way) if it did not start with a decimal digit. Or it would be
considered a decimal literal if it did not contain/end with “c” (allowed
would only be “e” followed by a decimal literal, for the
exponential/scientific decimal format). But as it does contain/end with “c”
that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
the entire expression would not compile and the entire PHP program would not
compile, being syntactically in error.
We have now ascertained that, as Thomas Mlynarczyk stated, “x11.11c” cannot
be a proper numeric literal in PHP (it would be an operation expression
[that would not compile, but that is unimportant from here]). As that is
the case, “'x11.11c'” also is not considered numeric in PHP, which is why
is_numeric('x11.11c')
must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
However, there appears to be an *actual* mismatch between PHP manual and
implementation in said PHP version as
is_numeric('0b11001001')
returns FALSE when according to the manual it should return TRUE (binary
integer literals are available since PHP 5.4.0 per the manual, and they do
compile and properly evaluate in tests there.
> [more flames]
It is a pity that too often you are not able to master your emotions in
order to participate in a factual discussion in a constructive way.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-12 20:35 -0400 |
| Message-ID | <kmpc98$gs4$1@dont-email.me> |
| In reply to | #9284 |
On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>>> Thomas Mlynarczyk wrote:
>>>>>> Sanders Kaufman schrieb:
>>>>>>>> if(is_numeric('x11.11c') returns TRUE
>>>>>>> Try it without the quotation marks around the number.
>>>>>>
>>>>>> Which number? x11.11c is not a number.
>>>>>
>>>>> The misconception might partially draw from the fact that 0x11 is a
>>>>> number,
>>>>> the hexadecimal representation of decimal 16¹ + 16⁰ = 17 (even in PHP).
>>>>> In other programming languages that require a leading “0” and do not
>>>>> have “.” as (concatenation) operator,
>>>>>
>>>>> x11.11c
>>>>>
>>>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>>> errors [1]).
>>>>>
>>>>> In PHP, however,
>>>>>
>>>>> x11.11c
>>>>>
>>>>> would be equivalent to
>>>>>
>>>>> (x11) . (11c)
>>>>>
>>>>
>>>> Wrong, as usual.
>>>>
>>>> <snip>
>>>
>>> Intentionally misquoted, as usual.
>>
>> And exactly what is wrong with what I quoted?
>
> In contrast to what you stated, exactly *nothing* is wrong with it when
> properly quoted; that is, *in context*, which is the point. Giving you the
> benefit of a doubt, you appear to have severe difficulty understanding the
> concept of context as such and the importance of context in quotations
> specifically; it would be good if you could work on that.
>
That was the beginning of your reply. There was no previous context to
quote.
>> The rest of your trash
>
> Not everything that you choose to ignore or fail to understand is “trash”
> because of that.
>
No, but almost *everything* you say is pure tripe. You can't blame this
on the "context".
>> was based on this incorrect premise; it would be a waste of bandwidth to
>> repost your entire tripe.
>
> As showed by the PHP output that I posted further below, and that you
> snipped, the premise is _not_ incorrect. To elaborate:
>
The premise is completely incorrect. 'x11.11c' is NEVER considered a
numeric value, as several other people (including me) have shown. And
the '.' is NEVER an operator when within a quoted string.
> “.” would be considered a concatenation operator here; there is no other
> production of the PHP grammar that fits the source code better. Numeric
> literals must not start with “x” in PHP, which precludes the possibility
> that “.” would be parsed as a decimal point of the literal “x11.11” (which,
> giving you the benefit of a doubt, might have been your assumption drawing
> from other programming languages that you might know).
>
Nope. Not when it is within a quoted string.
> As a result, “x11“ would be considered a constant's identifier; because such
> a constant would likele be undeclared, it would be parsed as if it was a
> string value containing the characters of the would-be identifier as
> characters (see the PHP Notices in the test, and the generated output for
> proof of that).
>
Nope, not unless there was a define ('x11',...) statement previous to
this. It is a string - plain and simple. But you don't understand such
a simple concept.
> “11c” would be considered a constant identifier as well (and treated the
> same way) if it did not start with a decimal digit. Or it would be
> considered a decimal literal if it did not contain/end with “c” (allowed
> would only be “e” followed by a decimal literal, for the
> exponential/scientific decimal format). But as it does contain/end with “c”
> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
> the entire expression would not compile and the entire PHP program would not
> compile, being syntactically in error.
>
Wrong again. In PHP you have to have a define() statement to create a
constant. It is part of string. However, that's way beyond your
comprehension.
> We have now ascertained that, as Thomas Mlynarczyk stated, “x11.11c” cannot
> be a proper numeric literal in PHP (it would be an operation expression
> [that would not compile, but that is unimportant from here]). As that is
> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>
No, it is a string value, nothing more, nothing less.
> is_numeric('x11.11c')
>
> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>
is_numeric('0x11') has nothing to do with the problem at hand.
> However, there appears to be an *actual* mismatch between PHP manual and
> implementation in said PHP version as
>
> is_numeric('0b11001001')
>
> returns FALSE when according to the manual it should return TRUE (binary
> integer literals are available since PHP 5.4.0 per the manual, and they do
> compile and properly evaluate in tests there.
>
Again, absolutely nothing to do with this problem.
>> [more flames]
>
> It is a pity that too often you are not able to master your emotions in
> order to participate in a factual discussion in a constructive way.
>
>
> PointedEars
>
It's a pity you are so stoopid that you can't understand even simple
concepts so as to be able to participate in an intelligent discussion.
I suggest you try washing dishes. It's more your speed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2013-05-13 11:07 +0200 |
| Message-ID | <9274580.Q9cWkUkHO0@PointedEars.de> |
| In reply to | #9285 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-05-13 09:02 -0400 |
| Message-ID | <kmqo2o$md1$1@dont-email.me> |
| In reply to | #9286 |
On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>>>>> Thomas Mlynarczyk wrote:
>>>>>>>> Sanders Kaufman schrieb:
>>>>>>>>>> if(is_numeric('x11.11c') returns TRUE
>>>>>>>>> Try it without the quotation marks around the number.
>>>>>>>>
>>>>>>>> Which number? x11.11c is not a number.
>>>>>>>
>>>>>>> The misconception might partially draw from the fact that 0x11 is a
>>>>>>> number, the hexadecimal representation of decimal 16¹ + 16⁰ = 17
>>>>>>> (even in PHP).
>
> To be clear, I was referring to *Sanders'* misconception.
>
>>>>>>> In other programming languages that require a leading
>>>>>>> “0” and do not have “.” as (concatenation) operator,
>>>>>>>
>>>>>>> x11.11c
>>>>>>>
>>>>>>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>>>>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>>>>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>>>>> errors [1]).
>>>>>>>
>>>>>>> In PHP, however,
>>>>>>>
>>>>>>> x11.11c
>>>>>>>
>>>>>>> would be equivalent to
>>>>>>>
>>>>>>> (x11) . (11c)
>>>>>>>
>>>>>>
>>>>>> Wrong, as usual.
>>>>>>
>>>>>> <snip>
>>>>>
>>>>> Intentionally misquoted, as usual.
>>>>
>>>> And exactly what is wrong with what I quoted?
>>>
>>> In contrast to what you stated, exactly *nothing* is wrong with it when
>>> properly quoted; that is, *in context*, which is the point. Giving you
>>> the benefit of a doubt, you appear to have severe difficulty
>>> understanding the concept of context as such and the importance of
>>> context in quotations specifically; it would be good if you could work on
>>> that.
>>
>> That was the beginning of your reply. There was no previous context to
>> quote.
>
> It was the text that *followed*, and that you snipped, that put the part of
> my statement that you quoted, in context.
>
The statement was wrong in ANY context. But you're too stoopid to
understand that. And by trying to defend your stoopidiy, you're just
making yourself seem even more stoopid.
You would have been much better off just admitting your statement was
wrong and moving on. But your ego doesn't allow that.
>>>> The rest of your trash
>>>
>>> Not everything that you choose to ignore or fail to understand is “trash”
>>> because of that.
>>
>> No, but almost *everything* you say is pure tripe. You can't blame this
>> on the "context".
>
> You proceed from the false assumption that if someone is wrong on one thing
> (and to date we have only *your* *opinion* on that) must be wrong on
> another.
>
Nope. The rest of your argument was based on a false premise.
>>>> was based on this incorrect premise; it would be a waste of bandwidth to
>>>> repost your entire tripe.
>>> As showed by the PHP output that I posted further below, and that you
>>> snipped, the premise is _not_ incorrect. To elaborate:
>>
>> The premise is completely incorrect. 'x11.11c' is NEVER considered a
>> numeric value, as several other people (including me) have shown. And
>> the '.' is NEVER an operator when within a quoted string.
>
> Apparently you do not understand that is_numeric() treats both numeric
> literals and numeric representations in string literals the same. Therefore
> it matters to the return value of is_numeric() if string content could be a
> numeric literal when used verbatim in PHP code. I have showed that and why
> it could not be a numeric literal, providing the rationale for the return
> value of is_numeric().
>
Unlike you, I understand EXACTLY what is_numeric() does. And I also
understand that 'x11' can NOT be a hexadecimal representation in PHP,
and a '.' within a quoted string is NEVER a concatenation character.
Neither of which do YOU understand.
>>> As a result, “x11“ would be considered a constant's identifier; because
>>> such a constant would likele be undeclared, it would be parsed as if it
>>> was a string value containing the characters of the would-be identifier
>>> as characters (see the PHP Notices in the test, and the generated output
>>> for proof of that).
>>
>> Nope, not unless there was a define ('x11',...) statement previous to
>> this. It is a string - plain and simple. […]
>
> The PHP output that I posted shows that a standalone identifier – such *as
> if* that string *content* was used in PHP code is met with a PHP Notice and
> is *treated as* I described above from then on. The Notice is issued then
> because the source code is ambiguous, therefore error-prone. As you
> confirmed, if a constant having that sequence of identifiers would be
> declared, the source code would change meaning.
>
Nope, it is NOT a standalone identifier, and it is NOT a constant. Once
again you show your stoopidity.
Also, the source code was NOT ambiguous. And defining a constant would
NOT change the meaning; but then once again you have no idea what you're
talking about.
> This is important because if a sequence of characters is potentially a
> constant identifier, it cannot be a numeric literal at the same time.
>
Nope, a constant identifier is NOT replaced within a quoted string.
You're just digging yourself deeper, Pointed Head.
>>> “11c” would be considered a constant identifier as well (and treated the
>>> same way) if it did not start with a decimal digit. Or it would be
>>> considered a decimal literal if it did not contain/end with “c” (allowed
>>> would only be “e” followed by a decimal literal, for the
>>> exponential/scientific decimal format). But as it does contain/end with
>>> “c”
>>> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
>>> the entire expression would not compile and the entire PHP program would
>>> not compile, being syntactically in error.
>>
>> Wrong again. In PHP you have to have a define() statement to create a
>> constant. It is part of string. […]
>
> I am aware that one needs define() for constants. This has nothing to do
> with the fact that an identifier is treated as a string value containing the
> identifiers characters if there is no constant declared with that
> identifier. And it has nothing to do with the fact that a constant cannot
> start with a decimal digit, or that a decimal literal cannot contain the
> character “c”. That therefore such a PHP program would be syntactical in
> error; that therefore, too, “x11.11c” cannot be a numeric literal, and that
> therefore, too, is_numeric('x11.11c') MUST return FALSE (which, contrary to
> the OP's claims, it does).
>
Obviously this is something new to you or you wouldn't have made that
previous statements. Nice try of backtracking, but it doesn't work.
>>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>>> cannot be a proper numeric literal in PHP (it would be an operation
>>> expression
>>> [that would not compile, but that is unimportant from here]). As that is
>>> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>>
>> No, it is a string value, nothing more, nothing less.
>
> It is a string value whose suitability to serve as a numeric value is being
> tested with is_numeric(). Therefore it matters what the PHP grammar has to
> say about numeric values.
>
It is not a constant like you indicate. Nice try of backtracking again.
>>> is_numeric('x11.11c')
>>>
>>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>>
>> is_numeric('0x11') has nothing to do with the problem at hand.
>
> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix make
> “0x11” a proper numeric (hexadecimal integer) representation as per the PHP
> grammar. Which is what is_numeric() is supposed to test.
>
Nope, that was not part of the question the OP asked; it is a spurious
and unrelated item.
>>> However, there appears to be an *actual* mismatch between PHP manual and
>>> implementation in said PHP version as
>>>
>>> is_numeric('0b11001001')
>>>
>>> returns FALSE when according to the manual it should return TRUE (binary
>>> integer literals are available since PHP 5.4.0 per the manual, and they
>>> do compile and properly evaluate in tests there.
>>
>> Again, absolutely nothing to do with this problem.
>
> Yes, it has. The OP claimed there was a bug in is_numeric(). If we assume
> the manual to be correct, this example shows that there actually *would be*
> a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on Debian GNU/Linux).
> But it would be *another* bug.
>
> That might be immaterial to you, but I consider it important for my fellow
> PHP developers to learn of it.
>
>
> PointedEars
>
Again, completely unrelated to what the OP asked. But you seem to show
your (lack of) intelligence by constantly bringing up completely
unrelated items, therefore complicating the matter unnecessarily. What
what's even funnier is when you show your stoopidity by being wrong in
so many of your claims.
Yes, you definitely have a "Pointed Head". No wonder you're so well
known as a troll in so many newsgroups.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web