440,772 Members | 906 Online
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
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 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 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 writes:Is creating strings really that expensive in Python? I'msurpised that you're saying that modifying a list and thencalling reverse() and join() is more efficient. I thoughtthat the overhead of compound objects such as lists ismore expensive than creating strings, which I thought whererather "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.