# Bug# 38 baseConvert

Dar Scott dsc at swcp.com
Wed Dec 10 03:57:48 EST 2003

```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

>
>
> 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

```