[ python-Feature Requests-1205239 ] Let shift operators take any integer value

[SourceForge.net]

Feature Requests item #1205239, was opened at 2005-05-19 12:54
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Albert Torpey (dtorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let shift operators take any integer value

Initial Comment:
Let:  
    1 >> -4 
be interpreted as:
    1 << 4

This should be easy to do.  It would be somewhat helpful for 
bit manipulations and multiplying by powers of two.  Without 
the change, my code is laced with sections like:

if y > 0:
    z = x << y
else:
    z = x >> -y

This is ugly and slow compared to a straight:
   z = x << y

There is a precedent.  See what is done with negative list 
indices for comparison.  It saves even less code with  x[len
(x)-i] becoming x[i].  The reason for doing it is code 
simplication and clarity.


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-27 12:22

Message:
Logged In: YES 
user_id=341410

Pardon me for believing that your RFE was applicable to any
object with an __lshift__ method.  Being that you did not
explicitly state that it was for integers only, merely that
you did use it with integers.

Regardless, changing integers to support negative shifts
would imply that floats should also support negative shifts,
and that all objects supporting __(l|r)shift__ methods also
support negative shifts.  One of Python's strengths is about
consistancy, my rude friend, not merely about your
particular use case for negative shifts.

You should also realize that because this would be a new
feature, it would have to wait until Python 2.5, which has
at least a year before it is to be released.  Are you
willing to wait a year to use this?  If not, you should get
the source for 2.4, modify it as you see fit, and run your
own version.

If waiting a year for 2.5 and for your change to maybe be
included or running your own version of 2.4 is not
sufficient, then you have a serious problem on your hands,
and no one here can help you.

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

Comment By: David Albert Torpey (dtorp)
Date: 2005-05-27 11:49

Message:
Logged In: YES 
user_id=681258

Forgive my directness, but the last post doesn't show the slightest 
clue about how Python works.  The existing test for a negative 
shift count takes place downstream from the interpreter in the 
int_lshift function in intobject.c (and the same for longobject.c).  
The RFE is to replace the line that raises a Value Error exception 
with a line that does something useful like flipping the sign of the 
argument and delegating to int_rshift.  That is a zero net change 
in code complexity.  The runtime of non-negative cases is 
likewise unchanged.  Is there someone else reading this who has 
an informed opinion?

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-27 11:06

Message:
Logged In: YES 
user_id=341410

Yes, I do have an objection.

On execution, either:
1. The interpreter would necessarily have to ask the
question "is this shift value positive or negative" in order
to possibly change which operation is to be executed.
2. Every shift operator would need to be rewritten to
support negative shift values.

Both of these solutions add compexity to what has been
historically (in all languages) a very simple operation, and
as the zen says "Simple is better than complex."

-1

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

Comment By: David Albert Torpey (dtorp)
Date: 2005-05-27 10:05

Message:
Logged In: YES 
user_id=681258

Yes, I use this on long integers.  And, the whole point of doing 
shifts is to avoid the costs of computing and multiplying by 
powers of two.  Besides the math equivalents do not express the 
algorithms as well or as directly as shifts.

Other than coming up with cumbersome workarounds (which I 
already had), do you have an objection to letting the shift 
operators use negative indices (in much the same way as with 
array indices)?


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-26 01:01

Message:
Logged In: YES 
user_id=341410

Is your code time critical?  Do your numbers have more than
53 bits of precision?  Do your numbers vary beyond 2**1024
or 1/2**1024?

If not, then the following should be sufficient for your
uses: int(x * 2**y)

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

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