I think you guys have convinced me that having >>> only isn't too bad (Jason will kill me now).
Does anyone here on php-dev have any additional thoughts?
I just want to point out that what convinced me wasn't the "anyone who knows twos complement would know that blah blah blah" argument. Don't forget that most of our PHP users aren't always that knowledgeable and we need to understand and respect that. Anyway, I just wanted to say that because I often get the feeling that people on php-dev forget that it's usually the more computer science oriented people on this list which isn't necessarily the average PHP user.

Andi

At 11:39 AM 10/29/2002 -0600, Jason T. Greene wrote:
On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> On Thu, 24 Oct 2002, Andi Gutmans wrote:
>
> > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> >
> > >The reality of twos-complement, bitwise arithmatic is that there are
> > >three basic shift operations: shift left, bitwise shift right, and
> > >arithmetic shift right. This simple fact is one of the basic ideas of
> > >dealing with twos-complement integers.
> >
> > I know that but I still wanted the opposite to be available to keep
> > things symmetrical. I'm not sure but I think CPU's do support both
> > logical and arithmetic shifts and just do the same with both (I might be
> > wrong though).
>
> Generally no, it's a waste of opcode space for modern CISC processors.
> RISC processors often have integrated barrel-shifters, so they don't need
> shift instructions at all.
>
> Intel carries over "arithmetic" shift right instructions from older
> architetures for backwards-compatibility with x86, but their RISC
> implementation (Itanium) does not contain support for the operation.
>
> One RISC example is ARM. They give you four shift options: Logical left,
> logical right, arithmetic right, and rotate right. Making the operation
> symmetrical is a waste of precious bit combinations, and would have meant
> either losing another shift operation or else adding another bit to the
> shift operation specifier, which means that another bit would have to be
> sacrificed elsewhere.
>
> Another example is SPARC, which implements shifting with discrete
> instructions, only implents one left shift operator. PowerPC does not
> implement it either.

Alpha has 3 instructions as well (log left, log right, arith right)

> > >Given this fact, there is no reason to have a bogus fourth operator in the
> > >name of symmetry. Mathematical operaters are simply not always
> > >symmetrical. There is no such thing as 'arithmetic shift left' or
> > >'logical shift left' in terms of twos-complement integers, so why invent
> > >it?
> >
> > I agree that they don't *have* to be symmetrical but I think it's
> > better.
>
> Better why? Anyone who understands twos-complement will understand (and
> expect) the ability to do those three operations, and will not be
> surprised by the lack of two left shifts. I argue that they *should NOT*
> be symmetrical because it is wrong.

I have to say I agree, introducing a bogus operator could actually cause
confusion. Java, which has been used several times in past arguments of
"why we should not do XYZ", has not had a problem with having only the
operators that actually exist.

> > >Second of all, my understanding of the here-doc operator is that it acts
> > >as a unary operation. I don't see the conflict with the binary
> > >application of <<<, given the example of unary and binary -, if it is
> > >absolutely neccessary to fulfill the (somewhat psychotic) need for
> > >symmetry where it is not realy needed, or even strictly correct.
> >
> > psychotic? Can we please have discussions on a professional and not
> > personal level?
>
> It is true though, unless you can give me a sound mathematical reason that
> the ops should exist... and saying "it looks right" or "it is easier" is
> not a valid reason, becuase to those with even basic twos-complement math
> background, it looks wrong and is not easier.
>
> > As far as I remember it does clash with here-docs. I'm pretty sure I
> > thought of an example a while back. I can try and think of one again. In
> > any case, I wouldn't want an overloaded operator. We try and keep away
> > of that kind of stuff with PHP.
Clashing can occur with Constant values, and functions with a \n in
front of the ().

> Very well... then let's not put in the nonsense operator, and just have
> three shift operations: <<, >>, and >>>.

I agree

> - D
>
> <[EMAIL PROTECTED]>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
-Jason

--
Jason T. Greene <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>




--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to