Bug# 38 baseConvert

[Wouter]

On 10 Dec 2003, at 09:56, use-revolution-request at lists.runrev.com wrote:

> Message: 9
> Date: Wed, 10 Dec 2003 01:57:48 -0700
> From: Dar Scott <dsc at swcp.com>
> Subject: Re: Bug# 38 baseConvert
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID: <EDB4B5D1-2AEE-11D8-98B8-000A9567A3E6 at swcp.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed

snip

> I fooled myself the first time I saw something like this with
> baseConvert().  No, the correct answer is 3509652390.  (This is the
> same as the bug at the top.)  If "D1310BA6" is interpreted as the bit
> pattern put into a signed (2's complement) variable, then the result
> should be -785314906.

Yes you are right. This means it is even worse.

>
>> 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.

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

> It would be nice if the range was expanded to that closer to the range
> for numerical results in Revolution.  Or indefinite.  I might be the
> only one interested.

Oh no , you are not :-)

> Currently, I do not use baseConvert() with negative values and wrap it
> in abs() to avoid the bug mentioned at the top for values 2^31 and up.
>
>
> However, there is a need for alternate representations of
> unsigned/signed (2's complement) 8/16/31/64/128-bit int/float values in
> communications, binary emulations and in working with binary files.
> 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.

> Values can be displayed in hex and in binary.  Some of the formats use
> the host encoding and thus are almost worthless; I do some fiddling to
> get the portable conversions I want.  My wish list includes better
> formats.
>
> I agree, Wouter.  Better base conversion and better binary-handling
> functions.  My preference is to leave baseConvert() something the
> mathematicians would like and find other functions for representing
> binary computerish values.
>
> However, if you proposed that base convert have an optional parameter
> (or two) that defined the holder for the intermediate value, I would
> not oppose that.  That could be handy.  It might be a string with "U32"
> as the default value.

Agreed.
I am also dreaming of things like this:
     get "D1310BA6"  <hex>xOr   "4B7A70E9"
And only do the conversions when really needed.

> Dar Scott
>
Thanks for the elucidations.

WA