Subject: bug#43764: closed (Re: bug#43764: Calc shift right broken)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 13 Oct 2020 09:58:02 +0000

Your bug report

#43764: Calc shift right broken

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
43764: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43764
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#43764: Calc shift right broken
From: Mattias Engdegård <[email-masked]>
To: Vincent Belaïche <[email-masked]>
Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked]
Date: Tue, 13 Oct 2020 11:56:50 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

9 okt. 2020 kl. 17.34 skrev Vincent Belaïche <[email-masked]>:

> 	• set bit width 0 would remove the automatic clipping meaning infinite width.

The previously mentioned patch implementing this has now been pushed to Emacs master. Thanks again for the suggestion!

I should also note the rationale for disabling left/right rotation when the word size is set to zero: while it would make sense to define

 (rotate-left x 1) =>
 x≥0: (shift-left x 1)
 x<0: (+ (shift-left x 1) 1)

 (rotate-right x 1) =>
 x≥0, x even: (shift-right x 1)
 x<0, x odd:  (shift-right x 1),

the two remaining cases of rotate right with {x≥0, x odd} or {x<0, x even} cannot result in a finite integer.

If someone has a better idea, or would like rotation to be implemented as a partial function according to the above definition, please comment. For now the bug is closed.

Subject: Calc shift right broken
From: Vincent Belaïche <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 2 Oct 2020 15:28:22 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Not sure whether this has to do with the other one.
I am on another machine, it is GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2020-05-17, modified by Debian

Anyway, I do this:

2 RET
;; display in hexa
d 6 RET
;; Raise to the power 32
32 ^
;; Shitf right by 30
C-u 32 b r
;; I get 0, whereas I expected 4

I have the impression that the old bigpos bigneg lisp based big intergers have been replaced by C bigintegers, and this is the root of all these regression.
Well, just a speculation.
  V.