#### Do you have a question? Post it now! No Registration Necessary. Now with pictures!

## Re: Butt ugly

I admit I should have read more precise. I have now looked up the word

commutative in the dictionary (damned english), and you can scratch most of

the above remark....

"related" is rather undefined here. I could make a case either way why + and

* are related, and why they are not, depending on what relation you're

talking about.

If one oversimplifies things, one could say adding (concating) strings is a

lot like adding numbers. Intuitively, you'd think that "hello" + "world" =

"helloworld" (which in some languages, it is). Because of PHP's ability to

cast variables on the fly there had to be another operator, so the operation

either used numerical value or strings. That might be the reason for the

same precedence. I'm not saying they are the same.

It's just a simple fact of knowing/learning that the . has the same

precedence. Once, when we were little, we learned + & - had the same in

math, en / & * also the same. How hard is it to learn that . has the same

precedence as + & -?

And like I said earlier: when either getting confused, or wanting to

increase readability, brackets are the way to go. They don't HAVE to be

necessary to use them.

Grtz,

--

Rik Wasmus

## Re: Butt ugly

Well, are intrinsically related as follows:

Adopting mathematical notation here, if we define:

f(x,c) = x + c

g(x,c) = x - c

then clearly:

f(,c) = g(,c)^-1

i.e. they're inverse operations.

A similar intrinsic relationship holds for .

No such magic exists for as far as I know.

To be honest, this is the only reason I can think of as well, that

concatenation is "a bit like" addition. Except it's not really, due to

the issue of commutativity, and the fact that there's no inverse

operation. Also, this logic implies that is related to , which

clearly isn't the case...

I'm not saying it's hard to learn; what I'm saying is that it's

unintuitive, because IMO the choice of its precedence is arbitrary. For

example, the code in my previous post leads to completely unintuitive

behaviour, IMO.

--

Oli

## Re: Butt ugly

"Related" is a loose term. The logical operators are sort of related

too, but they are have different precedence. One way to look at it is

that we want to preserve linearity at a given precedence level. Say we

have the express 1 + 3 - 5 + 7. We can think of it as the transform

(+3), (-5), and (+7) on the vector (1). These transforms can be applied

at any order. Likewise when we have 5 * 6 / 10, we can do either the

multiplication or the division first without affecting the result. Now

if we look at 0 & 0 | 1. Performing (&0) first yields 1, while doing

(|1) first yields 0.

Probably has something to do with + being overloaded for strings in

PHP's early days. I don't see any harm though in splitting . out to its

own level. Who in their right mind would do a string concatenation only

to have the result destroyed by the math operation?

## Re: Butt ugly

Rik wrote:

Well, I didn't say - or / is communtative. Substraction and division

are derived from addition and multiplication. The latters are

fundamental operation and you want to preserve their properties since

they underpin everything else.

It's been ages since I took linear algebra, but I remember correctly,

you have a proper vector space only if

1. Addition is communtative

2. There is a zero vector such that A + 0 = A

3. Multiplication is communtative

4. There is a unity vector such that 1 x A = A

If addition is not communtative, you end up with non-linear math.

String concatenation is not communtative and it's not associative with

addition.

No, you're saying it. Unless we've entered an alternative universe

where logic doesn't matter, the statement "addition is communtative"

does not imply "substraction is communtative."

Well, I didn't say - or / is communtative. Substraction and division

are derived from addition and multiplication. The latters are

fundamental operation and you want to preserve their properties since

they underpin everything else.

It's been ages since I took linear algebra, but I remember correctly,

you have a proper vector space only if

1. Addition is communtative

2. There is a zero vector such that A + 0 = A

3. Multiplication is communtative

4. There is a unity vector such that 1 x A = A

If addition is not communtative, you end up with non-linear math.

String concatenation is not communtative and it's not associative with

addition.

No, you're saying it. Unless we've entered an alternative universe

where logic doesn't matter, the statement "addition is communtative"

does not imply "substraction is communtative."

## Re: Butt ugly

'string'

...but that's not how the precedence is defined, the '*' multiplication has

higher precedence than '+' addition.

Your 'mathematical' examples are correct. Your last example is not... you

are taliking about two different things. The '.' operator is NOT

mathematical addition. The last example provides the correct answers:

"0." . 7 + 5 =

"0.7" + 5 =

5.7

since in this example the '.' is encountered first it must act on what it

knows and it knows what is to the immediate left and immediate right and

that is a 'string' and a number. The number 7 is converted to a string and

CONCATED to "0." making "0.7", then the '+' is encountered and it applies

itself to "0.7" and 5 resulting in a number whos value is 5.7 because the

string contains no leading alpha characters is converted to a number

(float/double) for the ADDITION process resulting in .7 + 5 = 5.7

...if you want the same answer then you must tell PHP how to handle the

precedence, so in this case you want to separate the math from the string

concatination:

".0" . (7 + 5) = "0.12"

(7 + 5) will always be computed as a single unit.

The bottom line is this... precedence can only 'guess' so much as to what

you the programmer wants and it normally does a great job. But when you

start mixing two different functions ('.' and '+') it has to make

assumptions, and those assumptions are to work on what is immediately known

and that is what is to the immediate left and right:

$str = 'C' . 'A' . 'T';

is computed/concated by:

$str = 'C' . 'A' . 'T';

$str = 'CA' . 'T';

$str = 'CAT';

and...

$str = 'C' . 'A' . 'T' + 100;

$str = 'CA' . 'T' + 100;

$str = 'CAT' + 100;

$str = 0 + 100;

$str = 100;

... the '+' ADDition function causes non-numeric strings to be zero (0)

and...

$str = 'C' . 'A' . 'T' . 100;

$str = 'CA' . 'T' . 100;

$str = 'CAT' . 100;

$str = 'CAT100';

... the '.' CONCATination function causes type conversion

http://us3.php.net/manual/en/language.operators.php#language.operators.precedence

Norm

## Re: Butt ugly

Norman Peelman wrote:

I'm sorry but you're missing the entire point of the discussion. The

point is that the ambiguity is illogical and should not exist. To use

your terminology, apples are apples, oranges are oranges. Putting them

all in one bin and then guess at what you've got is stupid.

I'm sorry but you're missing the entire point of the discussion. The

point is that the ambiguity is illogical and should not exist. To use

your terminology, apples are apples, oranges are oranges. Putting them

all in one bin and then guess at what you've got is stupid.

## Re: Butt ugly

what

known

So, what would you want to happen? Should the parser go through each

entire string looking for math equations first then string everything

together after. I'm thinking that the problem is probably the loose type

casting of the language. I'm thinking that under normal circumstances math

is not normally done within a string.

Normally: (oldskool, no mistake as to what is expected)

$sum = 7 + 7;

$str = 'sum = ';

echo $str , $sum;

outputs:

sum = 14

...so there you have it, no ambiguity. Ambiguity only comes into play when

programmers use tricky/bad programming practices because PHP will 'attempt'

to give them what they want. Ambiguity comes into play when new programmers

who haven't rtfm/googled/etc. rely on code snippets found here and there to

piece together something they barely understand to begin with. PHP is meant

to be learned easily (but not meant to teach programming knowledge/habits)

by allowing leeway in programming style. This leeway allows

experienced/advanced programmers to use the language to their advantage.

The bottom line is that '.' and '+' are/were not really meant to be used at

the same time as one works with strings and one works with mathematics. So

normally there would be no ambiguity. Type casting 'allows' it to be done so

that someone who has an understanding of what's going on can proceed without

having to use/write functions to convert strings and numbers back and forth.

If you want:

$a = 'If you multiply ' + 2 + 5 + 3 + ' by ' + 2

*** 5 + ' you get ' + 10 ***

10;

then you're asking too much of one operator let alone the parser.

---

Norm

## Re: Butt ugly

Norman Peelman said the following on 29/05/2006 00:05:

Who has suggested anything of the sort?

Says who?

There's no ambiguity; the behaviour is well-defined. However, there

Assuming you mean "overload to do both string concatenation and

addition", then you may well be right, it probably wouldn't be possible

to come up with a sensible precedence scheme so that the above example

gave the same result as:

$a = 'If you multiply ' . (2 + 5 + 3) . ' by ' . (2 * 5) . ' you get ' .

(10 * 10);

However, we're not talking about operator overloading. What we're

talking about is the operator precedence in PHP being unintuitive. If

there were an "intuitive" operator precedence (with lower than

), then the code below would give the same result:

$a = 'If you multiply ' . 2 + 5 + 3 . ' by ' . 2 * 5 . ' you get ' . 10

* 10;

--

Oli

Who has suggested anything of the sort?

Says who?

There's no ambiguity; the behaviour is well-defined. However, there

***is***unintuitive behaviour.Assuming you mean "overload to do both string concatenation and

addition", then you may well be right, it probably wouldn't be possible

to come up with a sensible precedence scheme so that the above example

gave the same result as:

$a = 'If you multiply ' . (2 + 5 + 3) . ' by ' . (2 * 5) . ' you get ' .

(10 * 10);

However, we're not talking about operator overloading. What we're

talking about is the operator precedence in PHP being unintuitive. If

there were an "intuitive" operator precedence (with lower than

), then the code below would give the same result:

$a = 'If you multiply ' . 2 + 5 + 3 . ' by ' . 2 * 5 . ' you get ' . 10

* 10;

--

Oli

## Re: Butt ugly

Norman Peelman wrote:

I have been saying the same thing and you keep missing it: the concat

operator should have its own precedence, lower than that of addition

and subtraction. What it involves is changing the line in the parser

definition from

%left '+' '-' '.'

to

%left '.'

%left '+' '-'

Now when the parser encounters "two plus two makes" . 2 + 2, it'll see

that the plus sign has higher precedence than the period (it's lower in

the definition) and will thus process it first.

Got it?

I have been saying the same thing and you keep missing it: the concat

operator should have its own precedence, lower than that of addition

and subtraction. What it involves is changing the line in the parser

definition from

%left '+' '-' '.'

to

%left '.'

%left '+' '-'

Now when the parser encounters "two plus two makes" . 2 + 2, it'll see

that the plus sign has higher precedence than the period (it's lower in

the definition) and will thus process it first.

Got it?

## Re: Butt ugly

Norman Peelman wrote:

I think that's the major point here:

typecasting vs. clear operations

One excludes the other in may occasions. PHP is very forgiving, allowing

floats, expontentials etc, but eval()ing strings using some mathmetical

parser before mathmatical equasions is to much to ask.

If one wants a pure, clear language, the parser should break at the

operations stated eralier, issuing a warning that 'something' isn't an

number (float, integer etc.), or 'something' isn't a string.

That would have a purity I can appreciate, allthough always casting posted,

get, database queried, filtered, or however one gets data, to a number will

be such a big pain, I do think PHP has it right with introducing some

leniency. The distance that leniency goes is the programmers responsibility

to learn, the consequences of that leniency are the programmers choice.

Grtz,

--

Rik Wasmus

I think that's the major point here:

typecasting vs. clear operations

One excludes the other in may occasions. PHP is very forgiving, allowing

floats, expontentials etc, but eval()ing strings using some mathmetical

parser before mathmatical equasions is to much to ask.

If one wants a pure, clear language, the parser should break at the

operations stated eralier, issuing a warning that 'something' isn't an

number (float, integer etc.), or 'something' isn't a string.

That would have a purity I can appreciate, allthough always casting posted,

get, database queried, filtered, or however one gets data, to a number will

be such a big pain, I do think PHP has it right with introducing some

leniency. The distance that leniency goes is the programmers responsibility

to learn, the consequences of that leniency are the programmers choice.

Grtz,

--

Rik Wasmus

## Re: Butt ugly

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Rik G. wrote:

It's called "operator precedente and automatic type casting":

Explicit operator precedence:

echo ("2 + 2 = " . 2) + 2;

echo ("2 + 2 = 2") + 2;

Wait, there is a sum operator over there, both operands must be

scalar-typed:

echo ( (int) "2 + 2 =2") + 2;

And, if you RTFM about casting a string to integer:

echo ( 2 ) + 2;

- --

- ----------------------------------

Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

http://acm.asoc.fi.upm.es/~mr/

Proudly running Debian Linux with 2.6.15-1-686 kernel, KDE3.5.0, and PHP

5.1.2-1+b1 generating this signature.

Uptime: 14:47:44 up 30 min, 1 user, load average: 0.88, 1.55, 1.32

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEeEsj3jcQ2mg3Pc8RAncbAKCAGbEAAgvBM/kyWYPN09nsptoozgCfZLMF

nGAewVd/7NJZGPbHLwUSWhQ=

=B+Vj

-----END PGP SIGNATURE-----

Hash: SHA1

Rik G. wrote:

It's called "operator precedente and automatic type casting":

Explicit operator precedence:

echo ("2 + 2 = " . 2) + 2;

echo ("2 + 2 = 2") + 2;

Wait, there is a sum operator over there, both operands must be

scalar-typed:

echo ( (int) "2 + 2 =2") + 2;

And, if you RTFM about casting a string to integer:

echo ( 2 ) + 2;

- --

- ----------------------------------

Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

http://acm.asoc.fi.upm.es/~mr/

Proudly running Debian Linux with 2.6.15-1-686 kernel, KDE3.5.0, and PHP

5.1.2-1+b1 generating this signature.

Uptime: 14:47:44 up 30 min, 1 user, load average: 0.88, 1.55, 1.32

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEeEsj3jcQ2mg3Pc8RAncbAKCAGbEAAgvBM/kyWYPN09nsptoozgCfZLMF

nGAewVd/7NJZGPbHLwUSWhQ=

=B+Vj

-----END PGP SIGNATURE-----

#### Site Timeline

- » PHP Guestbook list on PHPKode.com
- — Next thread in » PHP Scripting Forum

- » success with pdf templates?
- — Previous thread in » PHP Scripting Forum

- » URL redirection
- — Newest thread in » PHP Scripting Forum

- » Seamless SSO
- — Last Updated thread in » PHP Scripting Forum

- » SSD partition alignment revisited
- — The site's Newest Thread. Posted in » Computer Hardware