unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Vincent Belaïche" <vincent.b.1@hotmail.fr>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	"43764-done@debbugs.gnu.org" <43764-done@debbugs.gnu.org>
Subject: bug#43764: Calc shift right broken
Date: Wed, 4 Nov 2020 11:14:20 +0000	[thread overview]
Message-ID: <PR3PR06MB684374B8D0EDFE525C2AB90684110@PR3PR06MB6843.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <550C4DEF-DBAA-4175-98BC-DB484A3B89CF@acm.org>

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

Dear Mattias,

Thank you very much for the patch, and sorry for the very very late feedback. I had a look through it, and I noticed that in math-binary-modulo-args of the code w is also tested for not being nil. Looking at it more closely I saw that word width is also taken into account when doing binary operation with modulo forms.

I can see no reason why modulo form would need some special nil case, and I suspect that at some point of time the bit-width clipping could be disabled by setting the width to nil. So now, don't we have two conventions in the code : 0 and nil. If so, that would be unfortunate for maintanability.

Also, I noticed that the Calc test suite does not have any test case (or I missed it) for binary operations + modulo forms.

Also, concerning your comment about the rotate right by n bits of numbers with non zero least significant n bits, and with disabled bit width clipping, Calc has the infinite mode (press 'm i'), so if you decide some day to make this sort of implementation, then you should emit an error w/o infinite mode, but have a +inf with infinite mode. A bit (n-1) equal to 1 won't cause any -inf, because two complement signing is not possible with disabled bit width clipping, as this would result in an infinite number of FFFFFF with negative finite numbers.

I also notice that when two's complement signing display is on (type 'O d 6'), and bit width is set to 0 to disable bit width clipping, then the signing display is done as if the TwosComp mode was off. I think that it is OK to do that, but when 'b w 0 RET' or 'O d 6' is pressed, which ever comes last, and we have this conflict, then a warning message should be emitted, something like « Twos complement sign display is ignored when bit word width is not specified ».

  Vincent.
________________________________
De : Mattias Engdegård <mattiase@acm.org>
Envoyé : mardi 13 octobre 2020 11:56
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : Lars Ingebrigtsen <larsi@gnus.org>; 43764-done@debbugs.gnu.org <43764-done@debbugs.gnu.org>
Objet : Re: bug#43764: Calc shift right broken

9 okt. 2020 kl. 17.34 skrev Vincent Belaïche <vincent.b.1@hotmail.fr>:

>        • 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.


[-- Attachment #2: Type: text/html, Size: 5276 bytes --]

  reply	other threads:[~2020-11-04 11:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 15:28 bug#43764: Calc shift right broken Vincent Belaïche
2020-10-02 20:49 ` Mattias Engdegård
2020-10-05  8:12   ` Lars Ingebrigtsen
2020-10-05 10:34     ` Mattias Engdegård
2020-10-06  1:28       ` Lars Ingebrigtsen
2020-10-08 12:24         ` Mattias Engdegård
2020-10-09 15:29           ` Mattias Engdegård
2020-10-09 15:34         ` Vincent Belaïche
2020-10-10 16:24           ` Mattias Engdegård
2020-10-10 16:31             ` Mattias Engdegård
2020-10-13  9:56           ` Mattias Engdegård
2020-11-04 11:14             ` Vincent Belaïche [this message]
2020-11-04 11:54               ` Mattias Engdegård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PR3PR06MB684374B8D0EDFE525C2AB90684110@PR3PR06MB6843.eurprd06.prod.outlook.com \
    --to=vincent.b.1@hotmail.fr \
    --cc=43764-done@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=mattiase@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).