Re: Bug# 38 baseConvert

[Wouter]

On 10 Dec 2003, at 09:56, [EMAIL PROTECTED] wrote:

Message: 9
Date: Wed, 10 Dec 2003 01:57:48 -0700
From: Dar Scott <[EMAIL PROTECTED]>
Subject: Re: Bug# 38 baseConvert
To: How to use Revolution <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution