Bug# 38 baseConvert

[Dar Scott]

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