How to convert a number to hex number?

[Ron Adam]

Bengt Richter wrote:
> On Wed, 09 Nov 2005 00:42:45 GMT, Ron Adam <rrr at ronadam.com> wrote:
> 
> 
>>
>>Bengt Richter wrote:
>>
>>>On 08 Nov 2005 08:07:34 -0800, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>>>
>>>
>>>
>>>>"dcrespo" <dcrespo at gmail.com> writes:
>>>>
>>>>
>>>>>>>>hex(255)[2:]
>>>>>
>>>>>'ff'
>>>>
>>>>'%x'%255 is preferable since the format of hex() output can vary.  Try hex(33**33).
>>>
>>>
>>>Not to mention (#@%*!-pletive deleted ;-)
>>>
>>> >>> hex(-255)[2:]
>>> 'xff'
>>> >>> hex(-255)
>>> '-0xff'
>>> >>> hex(-255&0xff)
>>> '0x1'
>>>
>>>Regards,
>>>Bengt Richter
>>
>>I just happen to have been playing around with converting bases the last 
>>couple of days.  (idonowhy) ;-)
>>
> 
> It seems to be one of those inevitable things, enjoy it ;-)

I do, it's one of the things that keeps me interested here and help me 
find new ideas to explore. :-)


> But you still use '-' + yourconversion(abs(x)) to deal with a negative number.
> That's what I was #@%*!-ing about. You can't see the 'bits' in the way one was
> used to with the old int values. My answer was a base-complement representation,
> of which base-16 is a particular case. See
> 
>     http://groups.google.com/group/comp.lang.python/msg/d8324946fcdff8f8
> 
> and the code in the second reference from there:
> 
>     http://groups.google.co.uk/group/comp.lang.python/msg/359927a23eb15b3e

It seems I came in the back door concerning this discussion.  I hadn't 
read those specific threads.

I think I see what direction you are going in, but I'm not sure what the 
actual goal is.

Originally two's compliment representations were used to efficiently 
store signed integers when memory and processors where both real 
expensive slow and small. It also allowed for getting a signed number 
into a register in one instruction when you only had 8 bit data lines. 
And it was/is useful when designing electronic gate logic.

So what is the need to use a compliment form in other bases now?  I 
suppose it can still save memory, using a byte to store a value that can 
be stored in a single bit does seem to be a bit wasteful.  Then again 
the same could be said for any ascii representation of numbers.

Probably the most efficient way is to keep the number as integers
where it will be stored in binary and only convert it to the desired 
base if it needs to be viewed with a __repr__ or __str__ method.

hmm...  I'm not sure at what point in Pythons int handling they get 
converted from binary to decimal?

In this case the bit/byte storage issue of negative numbers would be 
side stepped.  But if you are working with hex or binary there still may 
be some situations you might still want to distinguish between the twos 
(or ones?) compliment hexadecimal or binary data.  Is this the correct 
issue you are referring to?

> I only put in characters for up to base 36, but it's a function parameter
> you can pass, so your digits ought to work if passed.
> The idea of base-complement is that the first digit is the zero digit for
> positive numbers and the digit for base-1 for negative numbers. This can
> be arbitrarily repeated to the left as fill without changing the numeric value.
> 
> so for base 10 one is 01 and -1 is 99, and for hex that
> is 01 and FF. For base 2, 01 and 11. Etc. To make a general
> literal you need a prefix to the data that tells you the base value
> to use in interpreting the data part. A la 0x01, I proposed
> 0b<base value in decimal>.<data part>
> So +1 -1 is 0b2.01 and 0b2.11 or octal 0b8.01 and 0b8.77 or
> decimal 0b10.01 and 0b10.99 and hex 0b16.01 and 0b16.ff

So you are using two's compliment.

     1  ->  0b2.01
    -1  ->  0b2.11      reverse bits, add 1
     3  ->  0b2.0011
    -3  ->  0b2.1101    or.. 2**4 - 3 = 13 = 1101

Then higher bases would be (base**digits)-n

     3  ->  0b8.03
    -3  ->  0b8.75      8**2 - 3

     1  ->  0b10.01
    -1  ->  0b10.99     10**2 - 1

So I presume you mean for edge cases...

    89  ->  0b10.89     is 89 or must it be 0b10.089 ?
   -89  ->  0b10.921


How about preceding two's compliment with a 1b instead of 0b.  then all 
the value digits can use as values and no padding is needed, but can 
still be used if desired.

     3  ->  0b2.11   or 0b2.00000011
    -3  ->  1b2.101     1b2.11111101

Signs could still be used also.

     3  ->   0b2.11
    -3  ->  -0b2.11

I'm still trying to decide if I like the period.  I think supporting 
arbitrary bases would be good.  I was surprised their wasn't support for 
it in the math module.  And partial support in the string module which I 
find kind of odd.  It seems to me all of these are integers so why not 
subclass them from ints and supply an appropriate __repr__ and __str__ 
method?

 >>> class hexx(int):
...   def __repr__(self):
...      return hex(self)
...
 >>> a = hexx(100)
 >>> a
0x64
 >>> b = a+a
 >>> b
200
 >>> type(b)
<type 'int'>
 >>> type(a)
<class '__main__.hexx'>
 >>>

Well, it would need a bit of work.  ;-)


> Algorithmically, minus 1 can be represented with a single data digit,
> but that's a style issue.

I think the representation of it is a style issue and the actual storage 
of it is a implementation issue.

>>Oh yeah,  I was thinking of using base62 to generate non-repeating id 
>>strings and wanted to try it out.
> 
> Hm, what were you going to use those for?

I was sort of just thinking something out.  For example, object id's 
tend to get reused so they can be a source of bugs if one isn't careful. 
  So it would be better to explicitly create a non repeating id for an 
object when it's desired.  Base62 is easily readable and sortable, but 
takes up nearly half as much space as integers do when they are 
converted to text.  But integers are faster and store internally more 
efficiently.

Also I wanted to see how much slower using strings instead of ints would 
be.  The base_iter() I posted is only about twice as slow as iterating 
an integer which is surprisingly good. I think python looses most of the 
advantage of integers because of byte code overhead, so the difference 
isn't as great as I thought it would be.

So it makes me think that in languages like python, either there is a 
lot of potential to improve math operations. And strings can be nearly 
as fast as ints in some cases.  Could it be that as computers get more 
powerful the differences between these becomes even less?  And other 
thoughts like these... etc... <shrug> :-)


> [...too tired to revisit the problem, just wanted to comment on the
>  sign/magnitude representation, hope I didn't typo too badly above ;-) ...]

I didn't see any typos, but I couldn't spell my way out of a paper bag 
if I needed too.  (spell checkers are my friends. ;-)

Cheers,
    Ron


> Regards,
> Bengt Richter