Okay... pythons build-in methods are quite fast. so is hex().
with about 64 kb memory i can write it with a 16 bit dictionary
where the dictionary generation itself is not yet optimized:
def genBitList(exp):
next = lambda now: [x+'0' for x in now]+[x+'1' for x in now]
result = [""]
for x i
Adam DePrince wrote:
>> BTW: Is there something like a sizeof() method for int numbers?
>
> import struct
> help( strict.calcsize )
Mh, that doesn't do what i want. I'd like to have something like:
def size(number):
return sizeof(number)
> Why one bit at a time?
Good question...
Here my new
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> Interesting. I wasn't aware of that optimization.
It's better not count on it. It's not there for Jython, IronPython, previous
versions of Python, etc. It is just there for the new cPython. And the fix
is so simple that it isn't worth disregardi
> It won't be any faster in CPython 2.4 or newer. This kind of string
> concatenation is optimized so as to be linear:
>
> $ python -m timeit -s "x = ''" "for i in xrange(1000): x += 'x'"
> 1000 loops, best of 3: 335 usec per loop
> $ python -m timeit -s "x = ''" "for i in xrange(1): x += 'x'
On Fri, 24 Mar 2006 15:40:17 +0100, "Diez B. Roggisch" <[EMAIL PROTECTED]>
wrote:
>Tim N. van der Leeuw wrote:
>> I also wonder if it wouldn't be faster to put the numbers into a list
>> and join the list into a string -- did you test with that?
>
>It will be faster - the naive string concatenatio
On Fri, 2006-03-24 at 12:55 +0100, Clemens Hepper wrote:
> Hello,
>
> I've written a little (optimized) method to get a bit-string:
>
> def bitstringneg(number, digits=32):
> """optimized for negative numbers"""
> result = ""
> for a in xrange(digits):
> if number & 1:
> result +=
Tim N. van der Leeuw wrote:
> I also wonder if it wouldn't be faster to put the numbers into a list
> and join the list into a string -- did you test with that?
It will be faster - the naive string concatenation is quadratic, whereas the
list-based approach is linear.
Diez
--
http://mail.python.
I wonder what causes one version to be faster for positive, and the
other faster for negative numbers? I can see that the pos-version
doesn't make as many iterations as the neg version, but it doesn't pad
the length of the result to the requested number of digits and
potentially produces more digit
Hello,
I've written a little (optimized) method to get a bit-string:
def bitstringneg(number, digits=32):
"""optimized for negative numbers"""
result = ""
for a in xrange(digits):
if number & 1:
result += '1'
else:
result += '0'
number >>= 1
return result
def bits
To look at the bit-structure i've implemented a little function:
def bitstring(number, digits=32):
"""lsb-->msb"""
result = ""
for a in xrange(digits):
if number & 1:
result += '1'
else:
result += '0'
number >>= 1
return result
I wonder if there is something lik
Actually, following up to my own reply:
3500 | 67 = 3567. So perhaps that sets your expectations for 3500 |
-67.
But try
-3500 | -67
for fun: it is -3
Bitwise or is no arithmetic and if you want to predict something about
the resulting integers, you should know something about how they are
xkenneth wrote:
> Why is 3500 | -67 equal to 3500 instead of -3567?
Well that's funny... On my computer, python says it's -67. Java also
says it's -67.
Haven't yet looked at the actual bits of both values.
What Python implementation and what machine do you have?
--Tim
--
http://mail.python.or
xkenneth schrieb:
> Why is 3500 | -67 equal to 3500 instead of -3567?
It isn't - its -67.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Why is 3500 | -67 equal to 3500 instead of -3567?
--
http://mail.python.org/mailman/listinfo/python-list
14 matches
Mail list logo
