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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
