Bug# 38 baseConvert

[Dar Scott]

On Wednesday, December 10, 2003, at 05:34 AM, Wouter wrote:

>>> put baseconvert("-3509652390",10,16) --> -D1310BA6  (wow again)
>>
>> This is correct in a pure base interpretation, but creates a strange
>> equality when viewed with the above result.

I was thinking of the problem that D1310BA6 = -D1310BA6 by transitivity 
of earlier results.

>
> Then shouldn't it be:
>    baseconvert("-785314906",10,16) --> D1310BA6
>    baseconvert("3509652390",10,16) --> 2ECEF45A
> and not the other way around ?

The first case assumes the value is put into a signed 32-bit (or 
greater) variable.  The lowest 32 bits of the variable is reinterpreted 
as unsigned 32-bit and then converted to hex.

In an extended baseConvert() this might be done with one of these:

     baseConvert("-785314906",10,16,"S32","U32")
     baseConvert("-785314906",10,16,"S48","U32")

I don't recognize a common interpretation in the second one.

>> For the most part, I use binaryEncode() and binaryDecode() for these.
>
> But these function also should be overhauled as to make the results 
> uniform over all platforms.

Yes.  There is a bugzilla enhancement request that adds portable 
formats, but leaves the host dependent ones for legacy.

> I am also dreaming of things like this:
>     get "D1310BA6"  <hex>xOr   "4B7A70E9"

What about this?

      get u32("xD1310BA6") bitXOR u32("x4B7A70E9")
      get hexXOR("B1310BA6","4B7A70E9")

Or something similar.  This could be done with no changes.

Dar