Bit shift oddity?

Bit shift oddity?

[Douglas Lewan]

I see the following:

    ELISP> (= (lsh -1 (lognot 0)) (lsh -2 (lognot 0)))

    t

    ELISP> (= (lsh -1 (lognot 0)) (lsh -3 (lognot 0)))

    nil

The first seems odd to me. Is it really what's expected?

-- 
,Doug
d.lewan2000@gmail.com
(908) 720 7908

You know, it's amazing how much closer to 0 that 8 067 332 is than 15 is. (2020 Oct 18)

Re: Bit shift oddity?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Sun, Oct 18, 2020 at 08:19:24PM -0400, Douglas Lewan wrote:
> I see the following:
> 
>    ELISP> (= (lsh -1 (lognot 0)) (lsh -2 (lognot 0)))
> 
>    t
> 
>    ELISP> (= (lsh -1 (lognot 0)) (lsh -3 (lognot 0)))
> 
>    nil
> 
> The first seems odd to me. Is it really what's expected?

The manual for lsh talks about "quirky behaviour" of lsh when
both arguments are negative, in the name of backward-compatibility
and suggests resorting to ash. Cf. the Emacs lisp manual "3.8
Bitwise Operations on Integers"

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Bit shift oddity?

[Douglas Lewan]

Thanks. I see the same behavior with (ash).

On 10/19/20 3:06 AM, tomas@tuxteam.de wrote:
> On Sun, Oct 18, 2020 at 08:19:24PM -0400, Douglas Lewan wrote:
>> I see the following:
>>
>>     ELISP> (= (lsh -1 (lognot 0)) (lsh -2 (lognot 0)))
>>
>>     t
>>
>>     ELISP> (= (lsh -1 (lognot 0)) (lsh -3 (lognot 0)))
>>
>>     nil
>>
>> The first seems odd to me. Is it really what's expected?
> The manual for lsh talks about "quirky behaviour" of lsh when
> both arguments are negative, in the name of backward-compatibility
> and suggests resorting to ash. Cf. the Emacs lisp manual "3.8
> Bitwise Operations on Integers"
>
> Cheers
>   - t

-- 
,Doug
d.lewan2000@gmail.com
(908) 720 7908

You know, it's amazing how much closer to 0 that 8 067 332 is than 15 is. (2020 Oct 18)

Re: Bit shift oddity?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Mon, Oct 19, 2020 at 03:48:01AM -0400, Douglas Lewan wrote:
> Thanks. I see the same behavior with (ash).

Well, it's not exactly the "same behaviour", the inequalities
seem to be the same, but the intermediate numbers are not.

FWIW:

  (dotimes (i 10)
    (let ((shift (- -1 i)))
      (insert (format "shift=%d res=%d\n"
                      shift
                      (ash shift (lognot 0))))))
  =>

  shift=-1 res=-1
  shift=-2 res=-1
  shift=-3 res=-2
  shift=-4 res=-2
  shift=-5 res=-3
  shift=-6 res=-3
  shift=-7 res=-4
  shift=-8 res=-4
  shift=-9 res=-5
  shift=-10 res=-5
  
I don't quite understand the result; I may look into it later.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Bit shift oddity?

[Gregory Heytings via Users list for the GNU Emacs text editor]

>
> I see the following:
>
>   ELISP> (= (lsh -1 (lognot 0)) (lsh -2 (lognot 0)))
>
>   t
>
>   ELISP> (= (lsh -1 (lognot 0)) (lsh -3 (lognot 0)))
>
>   nil
>
> The first seems odd to me. Is it really what's expected?
>

Yes, it's what is expected.  The docstring of lsh says:

"(lsh VALUE COUNT) ... If COUNT is negative, shifting is actually to the 
right. In this case, if VALUE is a negative fixnum treat it as unsigned 
..."

-1 (decimal) = 111...111 (binary)
-2 (decimal) = 111...110 (binary)

If you shift these two numbers to the right, you get the exact same 
result: 011...111, that is, `most-positive-fixnum'.

Re: Bit shift oddity?

[Stefan Monnier]

>                       (ash shift (lognot 0))))))

Could there be a simple misunderstanding: the shift amount is the
*second* argument.  Here you always pass (lognot 0), which is -1, so
it's a right shift by 1, IOW a kind of "divide by 2".

>   shift=-1 res=-1
>   shift=-2 res=-1
>   shift=-3 res=-2
>   shift=-4 res=-2
>   shift=-5 res=-3
>   shift=-6 res=-3
>   shift=-7 res=-4
>   shift=-8 res=-4
>   shift=-9 res=-5
>   shift=-10 res=-5

That does indeed look like divide by 2 to me (rounding toward -∞).


        Stefan

Re: Bit shift oddity?

[Douglas Lewan]

Nice. Thank you.

On 10/19/20 5:23 AM, Gregory Heytings wrote:
>
>>
>> I see the following:
>>
>>   ELISP> (= (lsh -1 (lognot 0)) (lsh -2 (lognot 0)))
>>
>>   t
>>
>>   ELISP> (= (lsh -1 (lognot 0)) (lsh -3 (lognot 0)))
>>
>>   nil
>>
>> The first seems odd to me. Is it really what's expected?
>>
>
> Yes, it's what is expected.  The docstring of lsh says:
>
> "(lsh VALUE COUNT) ... If COUNT is negative, shifting is actually to 
> the right. In this case, if VALUE is a negative fixnum treat it as 
> unsigned ..."
>
> -1 (decimal) = 111...111 (binary)
> -2 (decimal) = 111...110 (binary)
>
> If you shift these two numbers to the right, you get the exact same 
> result: 011...111, that is, `most-positive-fixnum'.

-- 
,Doug
d.lewan2000@gmail.com
(908) 720 7908

You know, it's amazing how much closer to 0 that 8 067 332 is than 15 is. (2020 Oct 18)

Re: Bit shift oddity?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Mon, Oct 19, 2020 at 11:14:52AM -0400, Stefan Monnier wrote:
> >                       (ash shift (lognot 0))))))
> 
> Could there be a simple misunderstanding: the shift amount is the
> *second* argument.

*AH!* (sound of slapping forehead).

Thanks.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]