Re: Unsigned Integer Literals?

[Magicks M <m4gicks@...>]

Okay so basically what happens is the negative numbers are used to represent more positive numbers, since there's the same amount of numbers in each range it works. (we encode the extra positive numbers as negative int64s if you like) The issue I have is the fact that the PiL section on uints clearly shows 13835058055282163712 being interpreted as a int64 and being represented as -4611686018427387904 which does not happen in my interpreter I get 1.3835058055282e+019 this is not a negative integer.

This direct quote from PiL 4th ed. is therefore incorrect:

We can write constants larger than 2^63 -1 directly, despite appearances:

  > x = 13835058055282163712 -- 3 << 62

 > x                        --> -4611686018427387904

It does not describe what happens. I want to know if there's a reason this is claimed to happen when in the demo, my interpreter and an ubuntu build of lua, I get a float.

It should be noted that 3 << 62 does indeed produce the negative integer you expect, and ("%u"):format(3 << 62) confirms that it is the number in question.

On Tue, Dec 4, 2018 at 4:43 AM Muh Muhten <muh.muhten@gmail.com> wrote:

On 12/3/18, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
> Le mar. 4 déc. 2018 à 00:11, Muh Muhten <muh.muhten@gmail.com> a écrit :
>
>> On 12/3/18, Magicks M <m4gicks@gmail.com> wrote:
>> > Quoting from Programming in lua:
>> >
>> >> We can write constants larger than 2^63 -1 directly, despite
>> appearances:
>> >>
>> >   > x = 13835058055282163712 -- 3 << 62
>> >>
>> >  > x                        --> -4611686018427387904
>> >>
>> > When I enter this example into an interpreter (you can try in the lua
>> demo)
>> > the number is cast to a float, is that supposed to happen?
>>
>> Since this numeric constant has neither radix point nor exponent, and
>> does not fit in an integer, it is not defined by the manual (§3.1):
>
>
>> > A numeric constant with a radix point or an exponent denotes a float;
>> otherwise, if its value fits in an integer, it denotes an integer.
>>
>> The claim in PIL is consistent with 5.3.0-2, but changed in 5.3.3. The
>> manual text in that section is the same. Of course, pre-5.3 versions
>> generally have the "new" behaviour due to using only floating-point
>> numbers.
>>
>
> But this integer exists !  The _expression_ (-2147483647 - 1) uses only
> integers within the positive subset, and produces an integer, even if its
> negation would produce a double with the Lua operator. This is the only
> integer (assuming integers are 32 bits) that has no distinct negation as an
> integer.
>
> If integers are compiled as 64-bit (normally the case on 64-bit target
> architecture where the C "int" type is 64-bit), then the unique integer
> without distinct negation is (-9223372036854775807-1).
>
> You may still have not understood this issue.
>
13835058055282163712 does not fit in a 64-bit integer.