Bug# 38 baseConvert
wouter.abraham at pi.be
Wed Dec 10 07:34:21 EST 2003
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
> 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
> 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.
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.
More information about the Use-livecode