Re: [ANN] Lua 5.2.0 (work1) now available

[David Kastrup <dak@...>]

Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:

>> Summary:
>> - Inputs to bit operations need to be converted in a consistent and
>>   platform-independent way, respecting modular arithmetic requirements.
>
> We would like to do that. But we do not know a reasonable way to do it
> in ANSI C89.
>
>
>> - Outputs of bit operations need to be signed.
>
> We still dissagree. I cannot see how bit.not(0) could not be equal
> to 0xffffffff.

modulo 2^32.  But that hardwires the 32bit assumption.  Emacs, as an
example, has operators logand, lognot, logior, logxor.  (lognot 0)
evaluates to -1.  Which is a resolution independent output.  You would
not be able to tell from that that Emacs happens to have 30bit integers.
most-positive-fixnum happens to be 2^29-1.  This had been 2^27-1 at one
point of time.  In XEmacs, it is 2^30-1.  During all those changes,
(lognot 0) remained -1, and as long as you did not overflow the integer
range with your initial numbers, all logical operations delivered the
same values.

When the mantissa of Lua's numbers exceeds 32 bits, there is no point of
not making those bits work as well.  When the LNUM patch has a smaller
numeric type to base on, there is no reason that it would need to move
to a larger presentation as long as the initial values fit into the
original space.

The sign-extended manner of implementing lognot, logand forms a closed
field over _any_ two's complement data type with n bits.

Without sign-extending, your results will depend on the size of the data
type even if the size of the input data is smaller!

-- 
David Kastrup