Re: [ANN] Lua 5.2.0 (alpha-rc2) now available

[David Kastrup <dak@...>]

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

>> >That was my guess too, but it would seem that band, bor, bxor are decent 
>> >alternatives.  It is UGLY.  If you look at the 5.2 reference index, the 
>> >first things you notice are _VERSION and bit32.XXXX.  Here's hoping this 
>> >will change before 5.2 is officially released.
>> 
>> In the same topic, is the '32' (in bit32 library) really relevant ? What happens when somebody hacks/improves bit32 library to deals with 64 bits integers (something that has been done in this very list ;-) )
>
> Being "32 bit" is not a limitation, but a "feature". A library dealing
> with 64-bit integers should be called "bit64", and probably be offered
> together with bit32, not as a replacement.

It is conceivable to create a "full-precision" bit library that will
provide as many bits as possible.

The principal problem I see with this is that you have to take your pick
among one's and two's complement number representation.

One's complement implies you have to be able to work with -0 as a proper
value (ugh).  Two's complement suffers the problem that the mantissa of
floating point numbers is symmetric around zero.  It happens that for k
bits of mantissa -2^k _is_ exactly representable, but having to
special-case this value is not making things prettier.

But it is pretty workable to work with 2^k different values given k bits
of mantissa (including the sign) in the floating point representation.

And if you want your results to be mod 2^32, you can mask to 32 bits
just at the end.  But if your input is representable by two's complement
in 32 bit, so will the result of any logical operation be.

-- 
David Kastrup