By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,772 Members | 906 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,772 IT Pros & Developers. It's quick & easy.

Inverse of int(s, base)?

P: n/a
Hi,

Is there an inverse function of int(s, base) where base
can be any number up to 36? I've searched the library
reference up and down, but haven't found anything.

For example, I need to work with base-24 numbers, which
can be parsed nicely with x = int(s, 24), but there
doesn't seem to be a way to convert integers back to
their base-24 representation as a string. (Of course,
I can define my own function in Python to do that, but
I wonder if there's a more efficient way.)

Best regards
Oliver

PS: This is what I'm using right now.

import string
str_digits = string.digits + string.ascii_lowercase

def str_base (x, base):
result = ""
while x:
result = str_digits[x % base] + result
x /= base
return result or "0"
print str_base(2065027084, 24) aj83kb4 int("aj83kb4", 24)

2065027084

--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code" (taken from comp.lang.awk FAQ)
Jul 18 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
ol**@secnetix.de wrote in message news:<2g***********@uni-berlin.de>...
Hi,

Is there an inverse function of int(s, base) where base
can be any number up to 36?
Yes, but for some reason it's not in the Python standard library.

....
PS: This is what I'm using right now.

import string
str_digits = string.digits + string.ascii_lowercase

def str_base (x, base):
result = ""
while x:
result = str_digits[x % base] + result
x /= base
The above line should be "x //= base", so it works under -Qnew.
return result or "0"


That works (for positive integers), but it might be more efficient to
not create a new string each time through the loop. An alternative
is:

def str_base(n, base=10):
if n == 0:
return '0'
isNegative = n < 0
if isNegative:
n = -n
result = []
while n > 0:
n, lastDigit = divmod(n, base)
result.append(str_digits[lastDigit])
if isNegative:
result.append('-')
result.reverse()
return ''.join(result)
Jul 18 '05 #2

P: n/a
da*****@yahoo.com (Dan Bishop) writes:
while x:
result = str_digits[x % base] + result
x /= base
The above line should be "x //= base", so it works under -Qnew.


Or just say:
x, r = divmod(x, base)
result = result + str_digits[r]
That works (for positive integers), but it might be more efficient to
not create a new string each time through the loop. An alternative is:

def str_base(n, base=10):

...

Similarly:

def str_base(n, base=10):
results = []
sign,n = ('','-')[n < 0], abs(n)
while n:
n, r = divmod(n, base)
results.append(str_digits[r])
results.reverse()
return sign + ''.join(results)
Jul 18 '05 #3

P: n/a
Paul Rubin <http://ph****@nospam.invalid> wrote:
da*****@yahoo.com (Dan Bishop) writes:
[...]
That works (for positive integers), but it might be more efficient to
not create a new string each time through the loop. An alternative is:

def str_base(n, base=10):

...

Similarly:

def str_base(n, base=10):
results = []
sign,n = ('','-')[n < 0], abs(n)
while n:
n, r = divmod(n, base)
results.append(str_digits[r])
results.reverse()
return sign + ''.join(results)


Cool, thanks both of you! Using divmod() is a good idea.

Is creating strings really that expensive in Python? I'm
surpised that you're saying that modifying a list and then
calling reverse() and join() is more efficient. I thought
that the overhead of compound objects such as lists is
more expensive than creating strings, which I thought where
rather "cheap and simple".

I work with strings a lot (in scripts for administration,
CGI programs etc.). And since strings are immutable, I
often have to create new ones. Now do you suggest I should
reconsider my approach and rather try to work with lists in
general, and only convert them back to strings for output
at the very end?

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 Munich
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

(On the statement print "42 monkeys" + "1 snake":) By the way,
both perl and Python get this wrong. Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake". -- Jim Fulton
Jul 18 '05 #4

P: n/a
> Is there an inverse function of int(s, base) where base
can be any number up to 36?


How about this?

)esab ,s(tni

:-)
Jul 18 '05 #5

P: n/a
Oliver Fromme <ol**@secnetix.de> writes:
Is creating strings really that expensive in Python? I'm
surpised that you're saying that modifying a list and then
calling reverse() and join() is more efficient. I thought
that the overhead of compound objects such as lists is
more expensive than creating strings, which I thought where
rather "cheap and simple".


Actually, for these int conversions (unless they're large long ints)
it's no big deal. The concern is when you're building up a long
string (say, a 10 kilobyte html page) by concatenating a lot of short
strings. When you say "a = a + b" the cost is proportional to
len(a+b), since that many chars must get copied around. In the
extreme case, suppose you build up a 10k web page one character at a
time:

for c in get_next_char():
page = page + c

The first iteration copies 1 character, the next iteration copies 2
chars, the next one 3 chars, etc. So the total amount of copying is
1+2+3+...+10000, which is around 50 million. In general it's O(N**2)
where N is the number of concatenations.

By comparison, when you append something to a list, the cost is
usually constant. There's extra space in the list for appending, so
nothing gets copied (if there's no extra space left, then stuff does
get copied and more space is allocated). So
for c in get_next_char():
page.append(c)
is much more efficient than string concatenation. At the end, you do
all the concatenation in one step with ''.join(page).

See also the StringIO and cStringIO library modules for possibly
preferable ways to do this.
Jul 18 '05 #6

P: n/a
Paul Rubin wrote:
Oliver Fromme <ol**@secnetix.de> writes:
Is creating strings really that expensive in Python? I'm
surpised that you're saying that modifying a list and then
calling reverse() and join() is more efficient. I thought
that the overhead of compound objects such as lists is
more expensive than creating strings, which I thought where
rather "cheap and simple".

Actually, for these int conversions (unless they're large long ints)
it's no big deal. The concern is when you're building up a long
string (say, a 10 kilobyte html page) by concatenating a lot of short
strings. When you say "a = a + b" the cost is proportional to
len(a+b), since that many chars must get copied around. In the
extreme case, suppose you build up a 10k web page one character at a
time:

[snip]

This is a good time to remind newbies that the root of
all evil lies in premature optimization (attributed to
Donald Knuth).

You could do worse than read Guido's anecdote:
http://www.python.org/doc/essays/list2str.html

Then, read Joel's discussion of "Shlemiel the painter's
algorithm":
http://www.joelonsoftware.com/articl...000000319.html

And an example of it here:
http://lambda.weblogs.com/discuss/msgReader$3130
(see one of the last reader's comments)

In conclusion: if you are absolutely positive that you
are only going to be adding together a few short
strings, then you gain much readability by just adding
together short strings. But if you are going to be
adding together lots of long strings, use lists and
only convert to a string at the end.

--
Steven D'Aprano
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.