[Python-bugs-list] [ python-Feature Requests-412227 ] explicit regular and arithmetic rshift

[SourceForge.net]

Feature Requests item #412227, was opened at 2001-03-29 11:41
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Dean Hall (dwhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: explicit regular and arithmetic rshift

Initial Comment:
Currently, Python uses auto-config tests to determine 
if its right shift operator ">>" performs regular 
right shift (RRS) or arithmetic (sign-extended) right 
shift (ARS).  Thus, Python's behavior is dependant on 
the C compiler.  The result for most platforms, is that 
">>" is ARS.

This leads to some troubling statements in Python 
syntax:

    0xffffffff >> 1 != 0xffffffffL >> 1

    -1 >> 5 == -1

The result of defaulting to ARS is that creating a RRS 
from the ">>" operator consumes more resources than 
necessary.  Whereas, if RRS were the default, it is 
quite easy to construct the ARS in python syntax:

    def ARShift(a,b):
        #bounds checking left out
        return ~((~a)>>b)

I would like to see these things happen:

1. Make explicit operators for ARS and RRS.
   I've seen ">>" and ">>>" used elsewhere.
2. Make ">>" default to RRS.
   It will behave more like hardware.

Final note: not having RRS available makes programming 
some algorithms such as Hamming codes and CRC difficult 
and inefficient.  We NEED it!

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

>Comment By: Tim Peters (tim_one)
Date: 2003-05-12 10:34

Message:
Logged In: YES 
user_id=31435

If it wasn't clear to the OP, Python's >> is always ARS.  It's 
C's that may differ across platforms, and the config tests are 
to determine whether Python can use the native C >> to get 
ARS behavior, or whether it has to build ARS on its own.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 04:10

Message:
Logged In: YES 
user_id=357491

In Python 2.4 all hex constants will be positive so you won't have to worry 
about this any longer.  Thus your example of the problem will no longer be 
an issue once Python 2.4 comes out.

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

Comment By: Gregory Smith (gregsmith)
Date: 2001-09-14 18:56

Message:
Logged In: YES 
user_id=292741

I see your problem; but this would not
generalize to long ints. Those have a
conceptually infinite sign extension, so
RRS can't ever work on negative
long numbers, and is the same as ARS
for positive ones.
Bearing in mind that even with longs,
negative numbers are generated by 
~ as well as -. So you gotta '&' with
a mask at some point in any case.

Even if you had your RRS operation,
I suspect you would only get the
behaviour you want for 32-bit values.
For 16-bit values, you'd have to ^0xFFFF
instead of ~, anyway; which is the
equivalent slowdown.


A >> in C depends not on the compiler 
but rather the type (signedness)
of the LHS; the real difference is that python
doesn't have an unsigned int!
It is true that all possible workarounds
tend to lead to more operators
in the inner loop than you want for
CRCs and things. I'm thinking of
starting a 'ecc' library project for py,
which could have a C implementation,
and thus go fast.





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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470