On Tuesday, December 9, 2003, at 09:58 AM, Wouter wrote:
in Bug# 38 on Bugzilla is stated:
x = FFFFFFFF baseConvert(x,16, 2) = 11111111111111111111111111111111 baseConvert(x,16,10) = -4294967295 <---
which should be : unsigned int 4294967295 signed int -1
By "unsigned int" and "signed int" we are placing an interpretation on the function that is not stated in its definition. Well, not stated by 2.1.1; I have yet to download 2.1.2.
But....
the reverse
baseConvert("4294967295",10,16) --> FFFFFFFF (correct)
baseConvert("-4294967295",10,16) --> -FFFFFFFF (negative hex, wow)
baseConvert("-1",10,16) --> -1 (hope it is not called a feature)
This can easily be called a feature with the right interpretation. As the one right above it.
also
put baseconvert("D1310BA6",16,10) --> -3509652390 (correct)
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.
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.
So the baseConvert(<expression>, 10, 16) gives correct results when using unsigned integers up to 4294967295.
4294967296 gives the zero result.
But the negative signed integers are considered as unsigned integers prefixed with a "-" and the result is rendered as a prefixed hex.
baseConvert("-1",10,16) should result in FFFFFFF1 as baseConvert("F1",16,10) results in 241.
If -1 is interpreted as the pattern in a 32-bit two's complement variable, then the result is FFFFFFFF. As I mentioned above, it might also be interpreted as the decimal number meaning negative one. That can also be represented as the hex number negative one. I like -1 base 10 = -1 base 16.
Or one should be able to choose between a signed or unsigned result in the baseConvert(<expression>, <source>, <dest>) function.
In its simplest form, base conversion is a numeral to numeral conversion. That is, it is string to string. The resulting string has the same _meaning_ as the input stream if read with the indicated base. The meaning, the in-between step implied by the function, is pure integer.
A decimal numeral can be used as a numerical value in Revolution, and if within a range, without loss.
My Transcript Dictionary does not define the behavior of the function for negative numerals.
Even with the above bug function baseConvert() is suitable for base conversions with numerical meanings within some range. If the bug mentioned at the top if fixed then baseConvert() would be suitable for base conversions within some more useful larger range. If the fix does not break the sign feature discovered, then it is reasonable that documentation expand the range to include negative numbers.
The documentation shows the allowed base between 2 and 36. The use is more general than alternate representations of a 32-bit container of some sort.
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.
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. 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.
Dar Scott
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
