[ python-Feature Requests-1205239 ] Let shift operators take any integer value
SourceForge.net
noreply at sourceforge.net
Fri May 27 19:05:00 CEST 2005
Feature Requests item #1205239, was opened at 2005-05-19 19:54
Message generated for change (Comment added) made by dtorp
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: David Albert Torpey (dtorp)
Date: 2005-05-27 17: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 08: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
More information about the Python-bugs-list
mailing list